- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 2606b87: MDEV-9117: Client Server capability negotiation for MariaDB specific functionality
by Sergei Golubchik 25 Nov '15

25 Nov '15

Hi, Sanja! On Nov 20, sanja(a)mariadb.com wrote: > revision-id: 2606b8744404f352b44c85ee23d41b12cddc3470 (mariadb-10.1.8-51-g2606b87) > parent(s): 81e4ce5e31ba0753d7acfab28bc6c3d83bfad1c6 > committer: Oleksandr Byelkin > timestamp: 2015-11-20 18:23:52 +0100 > message: > > MDEV-9117: Client Server capability negotiation for MariaDB specific functionality > > diff --git a/client/mysql.cc b/client/mysql.cc > index 92324c6..e242c25 100644 > --- a/client/mysql.cc > +++ b/client/mysql.cc > @@ -152,7 +152,7 @@ static ulong opt_max_allowed_packet, opt_net_buffer_length; > static uint verbose=0,opt_silent=0,opt_mysql_port=0, opt_local_infile=0; > static uint my_end_arg; > static char * opt_mysql_unix_port=0; > -static int connect_flag=CLIENT_INTERACTIVE; > +static ulong long connect_flag=CLIENT_INTERACTIVE; Either "ulonglong" or "unsigned long long". But not "ulong long", please. > static my_bool opt_binary_mode= FALSE; > static int interrupted_query= 0; > static char *current_host,*current_db,*current_user=0,*opt_password=0, > diff --git a/include/mysql.h b/include/mysql.h > index f088ad6..d398734 100644 > --- a/include/mysql.h > +++ b/include/mysql.h > @@ -270,7 +270,7 @@ typedef struct st_mysql > unsigned long thread_id; /* Id for connection in server */ > unsigned long packet_length; > unsigned int port; > - unsigned long client_flag,server_capabilities; > + unsigned long long client_flag,server_capabilities; This is an incompatible change, it breaks the ABI. If we have to have this change in libmysqlclient, you can put the new flags in the extension area. But, really, perhaps you should switch to Connector/C? > unsigned int protocol_version; > unsigned int field_count; > unsigned int server_status; > diff --git a/sql-common/client.c b/sql-common/client.c > index 609eef5..e108c4b 100644 > --- a/sql-common/client.c > +++ b/sql-common/client.c > @@ -2672,15 +2673,26 @@ static int send_client_reply_packet(MCPVIO_EXT *mpvio, > if (mysql->client_flag & CLIENT_PROTOCOL_41) > { > /* 4.1 server and 4.1 client has a 32 byte option flag */ > - int4store(buff,mysql->client_flag); > + bzero(buff+9, 32-9); > + if (mysql->server_capabilities & MARIADB_CLIENT_EXTENDED_FLAGS) > + { > + DBUG_ASSERT(mysql->client_flag & CLIENT_LONG_PASSWORD); 1. add DBUG_ASSERT(mysql->client_flag & CLIENT_PROTOCOL_41) 2. define CLIENT_LONG_PASSWORD to be 0 and CLIENT_MYSQL to be 1. Currently CLIENT_LONG_PASSWORD is not used anywhere, it's never checked. So you can safely define it to be 0 and use bit 1 for CLIENT_MYSQL, as we've discussed. > + /* > + first part of bytes - CLIENT_LONG_PASSWORD to signal mariadb extensions > + */ > + mysql->client_flag|= MARIADB_CLIENT_EXTENDED_FLAGS; > + int4store(buff, (mysql->client_flag & (~CLIENT_LONG_PASSWORD))); I think MariaDB clients should never set CLIENT_MYSQL. Independently from MARIADB_CLIENT_EXTENDED_FLAGS. > + int4store(buff + 28, (mysql->client_flag >> 32)); > + } > + else > + int4store(buff, mysql->client_flag); > int4store(buff+4, net->max_packet_size); > buff[8]= (char) mysql->charset->number; > - bzero(buff+9, 32-9); > end= buff+32; > } > else > { > - int2store(buff, mysql->client_flag); > + int2store(buff, (mysql->client_flag & 0xffff)); > int3store(buff+2, net->max_packet_size); > end= buff+5; > } > @@ -3682,7 +3697,20 @@ CLI_MYSQL_REAL_CONNECT(MYSQL *mysql,const char *host, const char *user, > if ((mysql->server_capabilities & CLIENT_PLUGIN_AUTH) && > strncmp(mysql->server_version, RPL_VERSION_HACK, > sizeof(RPL_VERSION_HACK) - 1) == 0) > + { > mysql->server_version+= sizeof(RPL_VERSION_HACK) - 1; > + mysql->server_capabilities|= ext_server_capabilities; > + if (!(mysql->server_capabilities & MARIADB_CLIENT_EXTENDED_FLAGS) && > + (mysql->client_flag & MARIADB_CLIENT_PROGRESS)) > + { > + /* old mariadb fix progress flag */ > + mysql->client_flag|= CLIENT_PROGRESS_OBSOLETE; > + if (mysql->server_capabilities & CLIENT_PROGRESS_OBSOLETE) > + { > + mysql->server_capabilities|= MARIADB_CLIENT_PROGRESS; > + } looks good, but please test this. New client, old server. And old client, new server too. > + } > + } > > if (pkt_end >= end + SCRAMBLE_LENGTH - SCRAMBLE_LENGTH_323 + 1) > { > diff --git a/tests/mysql_client_test.c b/tests/mysql_client_test.c > index 98f42ff..255ac25 100644 > --- a/tests/mysql_client_test.c > +++ b/tests/mysql_client_test.c > @@ -15336,7 +15336,7 @@ static void test_mysql_insert_id() > > myheader("test_mysql_insert_id"); > > - rc= mysql_query(mysql, "drop table if exists t1"); > + rc= mysql_query(mysql, "drop table if exists t1,t2"); why? > myquery(rc); > /* table without auto_increment column */ > rc= mysql_query(mysql, "create table t1 (f1 int, f2 varchar(255), key(f1))"); > @@ -16186,6 +16186,10 @@ static void test_change_user() > sprintf(buff, "drop database if exists %s", db); > rc= mysql_query(mysql, buff); > myquery(rc); > + sprintf(buff, "set local sql_mode=''"); why? > + rc= mysql_query(mysql, buff); > + myquery(rc); Regards, Sergei

3 7

[Maria-developers] Please review a simple patch changing shift/reduce conflicts from 160 to 121
by Alexander Barkov 23 Nov '15

23 Nov '15

Hi, The patch is for 10.2 (but should probably be safe for 10.1 as well) Thanks.

2 1

Re: [Maria-developers] [Commits] 334323b: MDEV-8542 - The "aria_recover" variable should be renamed "aria_recover_options"
by Sergei Golubchik 23 Nov '15

23 Nov '15

Hi, Sergey! On Nov 20, Sergey Vojtovich wrote: > revision-id: 334323bb3e5ca973cf239dce21a7d5510407f230 (mariadb-10.1.8-59-g334323b) > parent(s): a1ab4314d1f88fa954a774c322709822d7b95344 > committer: Sergey Vojtovich > timestamp: 2015-11-20 17:36:23 +0400 > message: > > MDEV-8542 - The "aria_recover" variable should be renamed "aria_recover_options" > to match MyISAM > > Added aria_recover_options, marked aria_recover as deprecated. > > diff --git a/mysql-test/suite/maria/maria-recover-master.opt b/mysql-test/suite/maria/maria-recover-master.opt > index 7582a38..976c388 100644 > --- a/mysql-test/suite/maria/maria-recover-master.opt > +++ b/mysql-test/suite/maria/maria-recover-master.opt > @@ -1 +1 @@ > ---loose-aria-recover=backup --loose-aria-log-dir-path=$MYSQLTEST_VARDIR/tmp > +--loose-aria-recover-options=backup --loose-aria-log-dir-path=$MYSQLTEST_VARDIR/tmp I'm not going to grep the code to see whether you've renamed all instances of 'aria[-_]recover' - I assume you did that and run tests too. > diff --git a/storage/maria/ha_maria.cc b/storage/maria/ha_maria.cc > index 2e2aa71..064d759 100644 > --- a/storage/maria/ha_maria.cc > +++ b/storage/maria/ha_maria.cc > @@ -256,6 +256,11 @@ static MYSQL_SYSVAR_ULONG(pagecache_file_hash_size, pagecache_file_hash_size, > 512, 128, 16384, 1); > > static MYSQL_SYSVAR_SET(recover, maria_recover_options, PLUGIN_VAR_OPCMDARG, > + "Deprecated and will be removed in a future release. Please use " > + "--aria-recover-options instead.", > + NULL, NULL, HA_RECOVER_DEFAULT, &maria_recover_typelib); > + Why? my_getopt does unambigous prefix matching, so --aria-recover will contnue to work after the rename without any explicit deprecated variables. So this one doesn't do any good. In fact, this variable has bad effects, without it 'aria-recov' (or any other unambigous prefix of aria-recover) would continue to work, but with this new deprecated variable 'aria-recov' will no longer be unambigous. > +static MYSQL_SYSVAR_SET(recover_options, maria_recover_options, PLUGIN_VAR_OPCMDARG, > "Specifies how corrupted tables should be automatically repaired", > NULL, NULL, HA_RECOVER_DEFAULT, &maria_recover_typelib); Regards, Sergei

2 2

[Maria-developers] any plans to bump soname for libmysqlclient.so?
by Honza Horak 19 Nov '15

19 Nov '15

Hi, mysql 5.7 bumped soname of the libmysqlclient.so. Are there any plans to do something like that in mariadb's libmysqlclient.so? I'm also wondering whether there are any particular plans to keep compatibility of the client library (libmysqlclient.so) between MariaDB and MySQL in the future. Honza

3 2

Re: [Maria-developers] [Commits] 2709165: MDEV-9128 - Compiling on IBM System Z fails
by Jan Lindström 18 Nov '15

18 Nov '15

Hi Sergey, Is this true only for innodb_plugin ? R: Jan On Wed, Nov 18, 2015 at 2:07 PM, Sergey Vojtovich <svoj(a)mariadb.org> wrote: > revision-id: 27091653333caed4691d1203f0b91d22d0e7927b > (mariadb-10.1.8-67-g2709165) > parent(s): bff6780806f4afed8faaf4c79b1593964564097e > committer: Sergey Vojtovich > timestamp: 2015-11-18 15:51:20 +0400 > message: > > MDEV-9128 - Compiling on IBM System Z fails > > Provided IBM System Z have outdated compiler version, which supports gcc > sync > builtins but not gcc atomic builtins. It also has weak memory model. > > InnoDB attempted to verify if __sync_lock_test_and_set() is available by > checking IB_STRONG_MEMORY_MODEL. This macro has nothing to do with > availability > of __sync_lock_test_and_set(), the right one is HAVE_ATOMIC_BUILTINS. > > --- > storage/innobase/include/os0sync.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/storage/innobase/include/os0sync.h > b/storage/innobase/include/os0sync.h > index 8e4b4f4..e192a3a 100644 > --- a/storage/innobase/include/os0sync.h > +++ b/storage/innobase/include/os0sync.h > @@ -487,7 +487,7 @@ os_atomic_clear(volatile lock_word_t* ptr) > __atomic_clear(ptr, __ATOMIC_RELEASE); > } > > -# elif defined(IB_STRONG_MEMORY_MODEL) > +# elif defined(HAVE_ATOMIC_BUILTINS) > > /** Do an atomic test and set. > @param[in,out] ptr Memory location to set to non-zero > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

[Maria-developers] Virtual columns and 'mysqldump' (and similar)
by Peter Laursen 18 Nov '15

18 Nov '15

I reported this bug report to Oracle: http://bugs.mysql.com/bug.php?id=79148 It is almost the same in MariaDB - but the error message is different, see SELECT VERSION(); -- 10.1.2-MariaDB-log CREATE TABLE `vc_test`.`t1`( `id` INT NOT NULL, `id3` INT AS ( id*3 ) VIRTUAL ); INSERT INTO `vc_test`.`t1` VALUES (1,3); -- retruns: Error Code: 1906 - The value specified for computed column 'id3' in table 't1' ignored SELECT * FROM t1; -- returns empty set So here the error message is that "value is ignored" (not that it is "not allowed"). It looks to me like somebody in MariaDB actually identified the problem, but forgot to finish things. The statement should succeed (maybe raise a warning), and the "specified value should be ignored" as the error message says, but what it in reality is not. What say?

3 12

Re: [Maria-developers] [Commits] 685c70d: MDEV-4829 BEFORE INSERT triggers dont issue 1406 error.
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Alexey! On Nov 17, Alexey Botchkov wrote: > revision-id: 685c70d39ac6599b448e86a3896a8c6836079b78 (mariadb-10.1.8-54-g685c70d) > parent(s): 0dfa0eef596ee677b55976793d632dc9b36928c7 > committer: Alexey Botchkov > timestamp: 2015-11-16 17:20:35 +0400 > message: > > MDEV-4829 BEFORE INSERT triggers dont issue 1406 error. > > The STRICT mode was reimplemented using Strict_handler instead of the > THD::abort_on_warning flag. I like the approach, in general. But 1. Let's do it in 10.2 2. Let's first wait for Bar to do his changes where only "true" fields will respect strict mode. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 5803178: MDEV-4829 BEFORE INSERT triggers dont issue 1406 error.
by Sergei Golubchik 17 Nov '15

17 Nov '15

Hi, Alexey! On Nov 17, Alexey Botchkov wrote: > revision-id: 580317835f9758a9536150e02031ff520e747089 (mariadb-10.1.8-54-g5803178) > parent(s): 0dfa0eef596ee677b55976793d632dc9b36928c7 > committer: Alexey Botchkov > timestamp: 2015-11-17 00:42:18 +0400 > message: > > MDEV-4829 BEFORE INSERT triggers dont issue 1406 error. > Turn the 'abort_on_warning' on for assigning value to fields. ok to push Regards, Sergei

1 0

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