- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] bff67808: MDEV-7806 - thread_pool_size is not auto-sized
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Sergey! On Nov 17, Sergey Vojtovich wrote: > revision-id: bff6780806f4afed8faaf4c79b1593964564097e (mariadb-10.1.8-66-gbff67808) > parent(s): c0216f1d02e63686f986fa8f352fdf6de61249a7 > committer: Sergey Vojtovich > timestamp: 2015-11-17 19:33:01 +0400 > message: > > MDEV-7806 - thread_pool_size is not auto-sized > > thread_pool_size is auto-sized before my_getopt(). But my_getopt starts from > resetting all options to their default values. So the auto-sized value is lost. > > Fixed by moving thread_pool_size auto-sizing after my_getopt(). Ok to push! Regards, Sergei

1 0

Re: [Maria-developers] [Commits] f21705d: MDEV-7806 - thread_pool_size is not auto-sized
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Sergey! On Nov 17, Sergey Vojtovich wrote: > revision-id: f21705dfbfcd87e46937222eb860727beb21a89b (mariadb-10.1.8-66-gf21705d) > parent(s): c0216f1d02e63686f986fa8f352fdf6de61249a7 > committer: Sergey Vojtovich > timestamp: 2015-11-17 13:13:47 +0400 > message: > > MDEV-7806 - thread_pool_size is not auto-sized > > thread_pool_size is auto-sized before my_getopt(). But my_getopt starts from > resetting all options to their default values. So the auto-sized value is lost. > > Fixed by autosizing default value directly. > > diff --git a/sql/sys_vars.cc b/sql/sys_vars.cc > index 682d803..e65a939 100644 > --- a/sql/sys_vars.cc > +++ b/sql/sys_vars.cc > @@ -3270,7 +3270,7 @@ static Sys_var_uint Sys_threadpool_size( > "This parameter is roughly equivalent to maximum number of concurrently " > "executing threads (threads in a waiting state do not count as executing).", > GLOBAL_VAR(threadpool_size), CMD_LINE(REQUIRED_ARG), > - VALID_RANGE(1, MAX_THREAD_GROUPS), DEFAULT(8), BLOCK_SIZE(1), > + VALID_RANGE(1, MAX_THREAD_GROUPS), DEFAULT(my_getncpus()), BLOCK_SIZE(1), > NO_MUTEX_GUARD, NOT_IN_BINLOG, ON_CHECK(check_threadpool_size), > ON_UPDATE(fix_threadpool_size) > ); Strange solution. Why wouldn't you move autosizing after config variables are read? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 4

Re: [Maria-developers] [Commits] 096fd8f: MDEV-9033 : Incorrect statements binlogged on slave with do_domain_ids=(...)
by Nirbhay Choubey 17 Nov '15

17 Nov '15

Hi Kristian, Can you please review this patch? - Nirbhay On Fri, Nov 13, 2015 at 5:23 PM, Nirbhay Choubey <nirbhay(a)mariadb.com> wrote: > revision-id: 096fd8f57664d0b3061f0e781a31bfa3cc6bf6cd > parent(s): a574407444fc3ea93ca88afa93dc18154251bf74 > committer: Nirbhay Choubey > branch nick: 10.1.b9033 > timestamp: 2015-11-13 17:23:49 -0500 > message: > > MDEV-9033 : Incorrect statements binlogged on slave with > do_domain_ids=(...) > > In domain ID based filtering, a flag is used to filter-out > the events that belong to a particular domain. This flag gets > set when IO thread receives a GTID_EVENT for the domain on > filter list and its reset at the last event in the GTID group. > The resetting, however, was wrongly done before the decision to > write/filter the event from relay log is made. As a result, the > last event in the group will always pass through the filter. > Fixed by deferring the reset logic. Also added a test case. > > --- > mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result | 73 ++++++++++++++++++++ > mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf | 20 ++++++ > mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test | 92 > +++++++++++++++++++++++++ > sql/slave.cc | 19 +---- > 4 files changed, 188 insertions(+), 16 deletions(-) > > diff --git a/mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result > b/mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result > new file mode 100644 > index 0000000..fdee91f > --- /dev/null > +++ b/mysql-test/suite/rpl/r/rpl_gtid_mdev9033.result > @@ -0,0 +1,73 @@ > +include/rpl_init.inc [topology=1->2->3] > +include/stop_slave.inc > +CHANGE MASTER TO > +MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (2,3); > +CHANGE MASTER "M_3" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = SERVER_MYPORT_3, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > +Warnings: > +Note 1937 SLAVE 'M_3' started > +Note 1937 SLAVE '' started > +include/stop_slave.inc > +CHANGE MASTER "M_1" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = MASTER_MYPORT, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (2,3); > +CHANGE MASTER TO > +MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (1,3); > +START ALL SLAVES; > +Warnings: > +Note 1937 SLAVE 'M_1' started > +Note 1937 SLAVE '' started > +CHANGE MASTER "M_2" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = SLAVE_MYPORT, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (1,3); > +CHANGE MASTER "M_3" TO > +MASTER_HOST = "127.0.0.1", MASTER_PORT = SERVER_MYPORT_3, > +MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > +IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > +Warnings: > +Note 1937 SLAVE 'M_3' started > +Note 1937 SLAVE 'M_2' started > +CREATE TABLE t1 (a INT PRIMARY KEY, b VARCHAR(10)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES (1, "m1"); > +INSERT INTO t1 VALUES (2, "m2"), (3, "m3"), (4, "m4"); > +include/save_master_gtid.inc > +include/sync_with_master_gtid.inc > +SELECT * FROM t1 ORDER BY a; > +a b > +1 m1 > +2 m2 > +3 m3 > +4 m4 > +include/sync_with_master_gtid.inc > +SELECT * FROM t1 ORDER BY a; > +a b > +1 m1 > +2 m2 > +3 m3 > +4 m4 > +# Cleanup > +DROP TABLE t1; > +include/save_master_gtid.inc > +include/sync_with_master_gtid.inc > +include/sync_with_master_gtid.inc > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > +STOP SLAVE "M_1"; > +RESET SLAVE "M_1" ALL; > +STOP SLAVE "M_2"; > +RESET SLAVE "M_2" ALL; > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > +include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > +include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > +# End of test. > diff --git a/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf > b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf > new file mode 100644 > index 0000000..80b6649 > --- /dev/null > +++ b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.cnf > @@ -0,0 +1,20 @@ > +!include ../my.cnf > + > +[mysqld.1] > +log-slave-updates > +loose-innodb > +gtid_domain_id=1 > + > +[mysqld.2] > +log-slave-updates > +loose-innodb > +gtid_domain_id=2 > + > +[mysqld.3] > +log-slave-updates > +loose-innodb > +gtid_domain_id=3 > + > +[ENV] > +SERVER_MYPORT_3= @mysqld.3.port > +SERVER_MYSOCK_3= @mysqld.3.socket > diff --git a/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test > b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test > new file mode 100644 > index 0000000..8b51d96 > --- /dev/null > +++ b/mysql-test/suite/rpl/t/rpl_gtid_mdev9033.test > @@ -0,0 +1,92 @@ > +--source include/have_innodb.inc > +--let $rpl_topology=1->2->3 > +--source include/rpl_init.inc > + > +--connection server_2 > +--source include/stop_slave.inc > +eval CHANGE MASTER TO > + MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (2,3); > +--replace_result $SERVER_MYPORT_3 SERVER_MYPORT_3 > +eval CHANGE MASTER "M_3" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $SERVER_MYPORT_3, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > + > +--connection server_3 > +--source include/stop_slave.inc > +--replace_result $MASTER_MYPORT MASTER_MYPORT > +eval CHANGE MASTER "M_1" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $MASTER_MYPORT, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (2,3); > +eval CHANGE MASTER TO > + MASTER_USE_GTID = SLAVE_POS, IGNORE_SERVER_IDS = (1,3); > +START ALL SLAVES; > + > +--connection server_1 > +--replace_result $SLAVE_MYPORT SLAVE_MYPORT > +eval CHANGE MASTER "M_2" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $SLAVE_MYPORT, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (1,3); > +--replace_result $SERVER_MYPORT_3 SERVER_MYPORT_3 > +eval CHANGE MASTER "M_3" TO > + MASTER_HOST = "127.0.0.1", MASTER_PORT = $SERVER_MYPORT_3, > + MASTER_USER = "root", MASTER_USE_GTID = SLAVE_POS, > + IGNORE_SERVER_IDS = (1,2); > +START ALL SLAVES; > + > +connection server_1; > + > +CREATE TABLE t1 (a INT PRIMARY KEY, b VARCHAR(10)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES (1, "m1"); > +INSERT INTO t1 VALUES (2, "m2"), (3, "m3"), (4, "m4"); > + > +--source include/save_master_gtid.inc > + > +connection server_2; > +--source include/sync_with_master_gtid.inc > +let $wait_condition=SELECT COUNT(*)=4 FROM t1; > +--source include/wait_condition.inc > +SELECT * FROM t1 ORDER BY a; > + > +connection server_3; > +--source include/sync_with_master_gtid.inc > +--source include/wait_condition.inc > +SELECT * FROM t1 ORDER BY a; > + > +--echo # Cleanup > +--connection server_1 > +DROP TABLE t1; > +--source include/save_master_gtid.inc > +--connection server_2 > +--source include/sync_with_master_gtid.inc > +--connection server_3 > +--source include/sync_with_master_gtid.inc > + > +--connection server_2 > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > + > +--connection server_3 > +STOP SLAVE "M_1"; > +RESET SLAVE "M_1" ALL; > + > +--connection server_1 > +STOP SLAVE "M_2"; > +RESET SLAVE "M_2" ALL; > +STOP SLAVE "M_3"; > +RESET SLAVE "M_3" ALL; > + > +--connection server_2 > +--source include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > + > +--connection server_3 > +--source include/sync_with_master_gtid.inc > +STOP SLAVE; > +CHANGE MASTER TO MASTER_USE_GTID = NO, IGNORE_SERVER_IDS = (); > + > +--echo # End of test. > diff --git a/sql/slave.cc b/sql/slave.cc > index fed171b..b93fb3d 100644 > --- a/sql/slave.cc > +++ b/sql/slave.cc > @@ -5870,22 +5870,6 @@ static int queue_event(Master_info* mi,const char* > buf, ulong event_len) > } > };); > > - if (mi->using_gtid != Master_info::USE_GTID_NO && > - mi->domain_id_filter.is_group_filtered() && > - mi->events_queued_since_last_gtid > 0 && > - ((mi->last_queued_gtid_standalone && > - !Log_event::is_part_of_group((Log_event_type)(uchar) > - buf[EVENT_TYPE_OFFSET])) || > - (!mi->last_queued_gtid_standalone && > - ((uchar)buf[EVENT_TYPE_OFFSET] == XID_EVENT || > - ((uchar)buf[EVENT_TYPE_OFFSET] == QUERY_EVENT && > - Query_log_event::peek_is_commit_rollback(buf, event_len, > - checksum_alg)))))) > - { > - /* Reset the domain_id_filter flag. */ > - mi->domain_id_filter.reset_filter(); > - } > - > if (mi->using_gtid != Master_info::USE_GTID_NO && mi->gtid_event_seen) > { > if (unlikely(mi->gtid_reconnect_event_skip_count)) > @@ -6071,6 +6055,9 @@ static int queue_event(Master_info* mi,const char* > buf, ulong event_len) > */ > mi->gtid_current_pos.update(&mi->last_queued_gtid); > mi->events_queued_since_last_gtid= 0; > + > + /* Reset the domain_id_filter flag. */ > + mi->domain_id_filter.reset_filter(); > } > > skip_relay_logging: > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

[Maria-developers] On the issue of Seconds_behind_master and Parallel Replication
by Kristian Nielsen 16 Nov '15

16 Nov '15

It was brought to my attention an issue with parallel replication and the Seconds_Behind_Master field of SHOW SLAVE STATUS. I have a possible patch for this, but I wanted to discuss it on the list, as it changes semantics compared to the non-parallel case. Each binlog event contains a timestamp (**) of when the event was created on the master. Whenever the slave SQL thread reads an event from the relay log, it updates the value of Seconds_Behind_Master to the difference between the slave's current time and the event's timestamp. Now in parallel replication, the SQL thread can read a large number of events from the relay log and queue them in-memory for the worker threads. So a small value of Seconds_Behind_Master means only that recent events have been queued - it might still be a long time before the worker threads have had time to actually execute all the queued events. Apparently the problem is (justified) user confusion about this queuing delay not being reflected in Seconds_Behind_Master. The same problem actually exists in the non-parallel case. In case of a large transaction, the Seconds_Behind_Master can be small even though there is still a large amount of execution time remaining for the transaction to complete on the slave. However, in the non-parallel case, at most one transaction can be involved. In the parallel case, the problem is amplified by the potential of thousands of queued transactions awaiting execution. So how to solve it? Attached is a patch that implements one possible solution: the Seconds_Behind_Master is only updated after a transaction commits, with the timestamp of the commit events. This seems more intuitive anyway. But it does introduce a semantic difference between the non-parallel and parallel behaviour for Seconds_Behind_Master. The value will in general be larger on a parallel slave than on a non-parallel slave, for the same actual slave lag. Monty suggested changing the behaviour also for non-parallel mode - letting Seconds_Behind_Master reflect only events actually committed, not just read from the relay log. This would introduce an incompatible behaviour for Seconds_Behind_Master, but could perhaps be done for 10.1, if desired. Doing it in stable 10.0 would be more drastic. So any opinions on this? - Should Seconds_Behind_Master be changed as per above in parallel replication (from 10.0 on)? - If not, any suggestion for another semantics for Seconds_Behind_Master in parallel replication? - If so, should the change to Seconds_Behind_Master also be done in the non-parallel case in 10.1? What about 10.0? - Any comments on the patch? Here is a test case that shows the problem. It simulates a slave catching up with a bunch of INSERT(SLEEP(1)). Without my patch, Seconds_Behind_Master=2 just after starting the parallel slave, while the non-parallel slave shows Seconds_Behind_Master=9. With my patch, the parallel slave shows Seconds_Behind_Master=11. ----------------------------------------------------------------------- --source include/have_innodb.inc --source include/have_binlog_format_statement.inc --let $rpl_topology=1->2 --source include/rpl_init.inc # Test various aspects of parallel replication. --connection server_1 ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB; CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format"); CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB; --save_master_pos --connection server_2 --sync_with_master --source include/stop_slave.inc SET GLOBAL slave_parallel_threads=1; --connection server_1 --disable_warnings INSERT INTO t1 VALUES (1, SLEEP(1)); INSERT INTO t1 VALUES (2, SLEEP(1)); INSERT INTO t1 VALUES (3, SLEEP(1)); INSERT INTO t1 VALUES (4, SLEEP(1)); INSERT INTO t1 VALUES (5, SLEEP(1)); INSERT INTO t1 VALUES (6, SLEEP(1)); INSERT INTO t1 VALUES (7, SLEEP(1)); INSERT INTO t1 VALUES (8, SLEEP(1)); INSERT INTO t1 VALUES (9, SLEEP(1)); INSERT INTO t1 VALUES (10, SLEEP(1)); --disable_warnings --save_master_pos --connection server_2 --source include/start_slave.inc SELECT SLEEP(1); --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc --sync_with_master --let $status_items= Seconds_Behind_Master --source include/show_slave_status.inc # Clean up. --connection server_2 --source include/stop_slave.inc SET GLOBAL slave_parallel_threads=DEFAULT; --source include/start_slave.inc --connection server_1 DROP TABLE t1; --source include/rpl_end.inc ----------------------------------------------------------------------- Thanks, - Kristian. ** The full detail is a bit more complex. Some events actually contains the time when the corresponding query _started_ executing, and another value which is the duration of execution. These are added by the slave to get the timestamp for the creation of the event (at the end of query exection). Also, the slave adjusts the timestamp with any time difference between the master and slave clock (eg. time zone for example).

6 10

[Maria-developers] MDEV-8109 unexpected CAST result
by Alexander Barkov 11 Nov '15

11 Nov '15

Hi Serg, Please review my patch for MDEV-8109. Thanks!

2 1

[Maria-developers] Please review MDEV-8140 patch
by chengxiaoz 10 Nov '15

10 Nov '15

Hi kentoku and Sergey, Please review mypatch for MDEV-8140. https://github.com/MariaDB/server/pull/61 Thanks.

3 3

[Maria-developers] Please review MDEV-8140 patch
by chengxiaoz＠189.cn 08 Nov '15

08 Nov '15

1 0

Re: [Maria-developers] [Commits] 7931ca4: MDEV-9024 Build fails with VS2015
by Sergei Golubchik 05 Nov '15

05 Nov '15

Hi, Wlad! Mostly ok, please see below On Nov 03, wlad(a)mariadb.com wrote: > revision-id: 7931ca4f89ad5cd38ea3dc54f1363b7de2fd3414 (mariadb-10.0.22-5-g7931ca4) > parent(s): fa1438cbf4307731a54ea4137d5f7d4b744cdfbc > committer: Vladislav Vaintroub > timestamp: 2015-11-03 11:32:00 +0100 > message: > > MDEV-9024 Build fails with VS2015 > > Fix build failures caused by new C runtime library > - isnan, snprintf, struct timespec are now defined, attempt to redefine them leads > - P_tmpdir, tzname are no more defined > - lfind() and lsearch() in lf_hash.c had to be renamed, declaration > conflicts with some C runtime functions with the same name declared > in a header included by stdlib.h > > Also fix couple of annoying warnings : > - remove #define NOMINMAX from config.h to avoid "redefined" compiler > warnings(NOMINMAX is already in compile flags) > > - disable incremental linker in Debug as well (feature not used much > and compiler crashes often) > > > Also simplify package building with Wix, require Wix 3.9 or later > (VS2015 is not compatible with old Wix 3.5/3.6) > > diff --git a/cmake/os/Windows.cmake b/cmake/os/Windows.cmake > index 4c01bab..fd6e739 100644 > --- a/cmake/os/Windows.cmake > +++ b/cmake/os/Windows.cmake > @@ -181,14 +184,13 @@ CHECK_SYMBOL_REPLACEMENT(S_IROTH _S_IREAD sys/stat.h) > CHECK_SYMBOL_REPLACEMENT(S_IFIFO _S_IFIFO sys/stat.h) > CHECK_SYMBOL_REPLACEMENT(SIGQUIT SIGTERM signal.h) > CHECK_SYMBOL_REPLACEMENT(SIGPIPE SIGINT signal.h) > -CHECK_SYMBOL_REPLACEMENT(isnan _isnan float.h) How can this be wrong? It checks whetherone should use _isnan instead of isnan. That seems like the kind of check that works both with old and new VS. > CHECK_SYMBOL_REPLACEMENT(finite _finite float.h) > diff --git a/config.h.cmake b/config.h.cmake > index 46eed79..a1d505f 100644 > --- a/config.h.cmake > +++ b/config.h.cmake > > -/* We don't want the min/max macros */ > -#ifdef __WIN__ > -#define NOMINMAX > -#endif I'd generally prefer to define symbols in headers, instead of putting everything into ever-growing compiler command line Besides, the minimal fix for the redefinition warning is -#define NOMINMAX +#define NOMINMAX 1 because -DNOMINMAX defines NOMINMAX to be 1, not empty. > /* > MySQL features > */ > diff --git a/mysys/lf_hash.c b/mysys/lf_hash.c > index aa96ca9..fa92971 100644 > --- a/mysys/lf_hash.c > +++ b/mysys/lf_hash.c > @@ -43,7 +43,7 @@ const int LF_HASH_OVERHEAD= sizeof(LF_SLIST); > > /* > a structure to pass the context (pointers two the three successive elements > - in a list) from lfind to linsert/ldelete > + in a list) from my_lfind to my_linsert/my_ldelete > */ > typedef struct { > intptr volatile *prev; > @@ -70,7 +70,7 @@ typedef struct { > cursor is positioned in either case > pins[0..2] are used, they are NOT removed on return > */ > -static int lfind(LF_SLIST * volatile *head, CHARSET_INFO *cs, uint32 hashnr, > +static int my_lfind(LF_SLIST * volatile *head, CHARSET_INFO *cs, uint32 hashnr, er... I don't like that. lfind/lsearch are internal static functions in lf_hash.c, they shouldn't need or use my_ prefix. Two alternatives: 1. #define lfind remap_lfind_for_win #include <my_global.h> #include <my_sys.h> #undef lfind 2. -static int lfind(LF_SLIST * volatile *head, CHARSET_INFO *cs, uint32 hashnr, +static int l_find(LF_SLIST * volatile *head, CHARSET_INFO *cs, uint32 hashnr, > const uchar *key, uint keylen, CURSOR *cursor, LF_PINS *pins) > { > uint32 cur_hashnr; > diff --git a/win/packaging/CMakeLists.txt b/win/packaging/CMakeLists.txt > index 3b9b72f..0535a48 100644 > --- a/win/packaging/CMakeLists.txt > +++ b/win/packaging/CMakeLists.txt > SET(CPACK_WIX_UPGRADE_CODE "49EB7A6A-1CEF-4A1E-9E89-B9A4993963E3") > - SET(CPACK_WIX_PACKAGE_NAME "MariaDB @MAJOR_VERSION@.@MINOR_VERSION@") > + SET(CPACK_WIX_PACKAGE_NAME "MariaDB ${MAJOR_VERSION}.${MINOR_VERSION}") > ELSE() > SET(CPACK_WIX_UPGRADE_CODE "2331E7BD-EE58-431B-9E18-B2B918BCEB1B") > - SET(CPACK_WIX_PACKAGE_NAME "MariaDB @MAJOR_VERSION@.@MINOR_VERSION@ (x64)") > + SET(CPACK_WIX_PACKAGE_NAME "MariaDB ${MAJOR_VERSION}.${MINOR_VERSION} (x64)") Weird. I was sure I've fixed this months ago :-[] Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 01bd373: MDEV-8437 - plugin variables conflict with bootstrap
by Sergei Golubchik 05 Nov '15

05 Nov '15

Hi, Sergey! On Nov 03, Sergey Vojtovich wrote: > revision-id: 01bd3737777f8f0cf2e1737d01a48033a7615b2a (mariadb-10.1.8-23-g01bd373) > parent(s): dc40d737d4af3cb0e272c58507ad54e4eb24be28 > committer: Sergey Vojtovich > timestamp: 2015-11-03 14:02:49 +0400 > message: > > MDEV-8437 - plugin variables conflict with bootstrap ok to push > There is no strong need to change password column: the only side effect is > that 4.0 -> 10.1 upgrades may get root/debian-sys-maint passwords stored in old > format. This should be perfectly acceptable, since all password at this point > are stored in old format. Regards, Sergei

2 3

Re: [Maria-developers] [Commits] 178cddd: MDEV-9082 - Debian: mysql_install_db is called on upgrade
by Sergei Golubchik 05 Nov '15

05 Nov '15

Hi, Sergey! On Nov 05, Sergey Vojtovich wrote: > revision-id: 178cddd664cb4ce2c6ccbe76c33e4fd2c1fc1b3d (mariadb-10.1.8-25-g178cddd) > parent(s): 2ef562d2c74297b0b92c4322697dad98767cc873 > committer: Sergey Vojtovich > timestamp: 2015-11-05 13:57:24 +0400 > message: > > MDEV-9082 - Debian: mysql_install_db is called on upgrade looks ok to me Regards, Sergei

1 0