May 2015 - developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 54e9df4: MDEV-7985: MySQL Users Break when Migrating to MariaDB, part 2
by Sergei Golubchik 05 May '15

05 May '15

Hi, Vicentiu! Two comments to the patch - see below. One general comment - you've done quite a bit of refactoring and this refactoring is *not* in 10.1 style. How should it be merged into 10.1? Should your changes be ignored (and not merged)? Should they be merged as is? Aren't they mostly unnecessary in 10.1? On May 05, vicentiu(a)mariadb.org wrote: > revision-id: 54e9df42d1f5837ae0df51e511ba48d3682be20d > parent(s): ae18a28500974351cf42fa3cac67c83e0647d510 > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-05-05 21:19:53 +0300 > message: > > MDEV-7985: MySQL Users Break when Migrating to MariaDB, part 2 > > Gave priority to password field when using a native authentication > plugin. > > Also, prevented a user from setting an invalid auth_string, when using > native authentication. > > diff --git a/sql/sql_acl.cc b/sql/sql_acl.cc > --- a/sql/sql_acl.cc > +++ b/sql/sql_acl.cc > @@ -862,6 +862,17 @@ static char *fix_plugin_ptr(char *name) > return name; > } > > +static bool plugin_is_native(const char* plugin) > +{ > + if (!plugin) > + return false; > + if ((my_strcasecmp(system_charset_info, plugin, > + native_password_plugin_name.str) == 0) || > + (my_strcasecmp(system_charset_info, plugin, > + old_password_plugin_name.str) == 0)) > + return true; > + return false; > +} I tried to compare plugin names almost always by pointers, not by comparing strings. That is, the string (as coming from the table or from the user) is strcmp'ed *once* and then replaced with a pointer to a static plugin name string. So I'd prefer it if you'd remove plugin_is_native() and instead used fix_user_plugin_ptr(). And then you remove fix_user_plugin_ptr() from acl_update_user() and acl_insert_user(). > /** > Fix ACL::plugin pointer to point to a hard-coded string, if appropriate > > @@ -1973,6 +2020,10 @@ static void acl_update_user(const char *user, const char *host, > acl_user->auth_string.length= auth->length; > if (fix_user_plugin_ptr(acl_user)) > acl_user->plugin.str= strmake_root(&acl_memroot, plugin->str, plugin->length); > + else > + set_user_salt(acl_user, acl_user->auth_string.str, > + acl_user->auth_string.length); what if auth_string is empty, how does the password take precedence in this case? > + > } > else > if (password[0]) Regards, Sergei

1 0

[Maria-developers] Please review: MDEV-7778 impossible create copy of table, if table contain default value for timestamp field
by Alexander Barkov 04 May '15

04 May '15

Hi Sergei, Please review a patch for MDEV-7778. As agreed on IRC, this is a merge from the latest MySQL, which has already fixed the problem. Greetings.

2 1

[Maria-developers] connect on IBM s390
by Alexander Barkov 04 May '15

04 May '15

Hi Olivier, MariaDB fails with some Connect tests on IBM s390. Please have a look into Debian build bot results: https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0&arch=s390x&ver=… I currently have a temporary access to an IMB s390 machine. It would be nice to fix the failures. Please find the mtr log attached. This is what I got on this test machine. The failures are very similar to what Debian build bot has. If you don't mind, I'd like to start fixing failures with "bin" and "dbf". 1. dbf.bin fails because Connect writes the DBF file header using the current platform endiannes, while from my understanding it should always write the header using little endianness. This should be fixed in the relevant DBF code in Connect. Can you please do this? 2. connect.bin fails because Connect treats columns in the current machine byte order, while Testbal.dat was created on a little endian machine. I can see a few options to fix this test failure: a. Disable on big endian machines. Bad idea. b. Make it possible to specify endiannes of a data file (or even per column), so we can tell in the tests that Testbal.dat (or its relevant columns) are in little endian format. Perhaps it's already possible in the latest Connect versions. Is it? If it's not, how difficult would be to implement this? c. Have two pre-created files Testbal_le.dat and Testbal_be.dat and load the one that suites the current machine endiannes. I'm thinking of going "c" now, with a hope to have both "b" and "c" in the future. If you agree, we'll need a big-endian version of Testbal.dat. 3. It seems that some other tests fail for the same reasons with #2. Having a big-endian version of the test data files, or having the endian flag in CREATE TABLE, would fix some of them. I suggest we fix "bin" first, and make sure it works fine an all platforms. Then do the same thing for the other tests. Thanks.

1 0

Re: [Maria-developers] [Commits] 4bff8b0: MDEV-7004 - Merge scalability fixes from 10.0-power
by jocelyn fournier 02 May '15

02 May '15

Hi Sergey, Just to be sure, currently MariaDB doesn't implement any Hardware Transactional Memory Built-in Functions ? If so, is there any plan to evaluate the gain they could offer to MariaDB ? Thanks and regards, Jocelyn Fournier Le 04/12/2014 14:45, svoj(a)mariadb.org a écrit : > revision-id: 4bff8b0b03ba82cd0ae6817b54de1780e89047ca > parent(s): 3526fe1b6000b2558290007e5cc3a1018850787c > committer: Sergey Vojtovich > branch nick: 10.1 > timestamp: 2014-12-04 17:44:46 +0400 > message: > > MDEV-7004 - Merge scalability fixes from 10.0-power > > Preallocate dynamic array and bitmap on mem_root to avoid expensive malloc. > This reduces number of allocations from 39 to 31 per OLTP RO transaction. > > --- > sql/opt_range.cc | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/sql/opt_range.cc b/sql/opt_range.cc > index 1a9ae3d..813508c 100644 > --- a/sql/opt_range.cc > +++ b/sql/opt_range.cc > @@ -1838,8 +1838,6 @@ void SQL_SELECT::cleanup() > index= key_nr; > head= table; > key_part_info= head->key_info[index].key_part; > - my_init_dynamic_array(&ranges, sizeof(QUICK_RANGE*), 16, 16, > - MYF(MY_THREAD_SPECIFIC)); > > /* 'thd' is not accessible in QUICK_RANGE_SELECT::reset(). */ > mrr_buf_size= thd->variables.mrr_buff_size; > @@ -1857,9 +1855,12 @@ void SQL_SELECT::cleanup() > file= head->file; > record= head->record[0]; > > - /* Allocate a bitmap for used columns (Q: why not on MEM_ROOT?) */ > - if (!(bitmap= (my_bitmap_map*) my_malloc(head->s->column_bitmap_size, > - MYF(MY_WME | MY_THREAD_SPECIFIC)))) > + my_init_dynamic_array2(&ranges, sizeof(QUICK_RANGE*), > + thd->alloc(sizeof(QUICK_RANGE*) * 16), 16, 16, > + MYF(MY_THREAD_SPECIFIC)); > + > + /* Allocate a bitmap for used columns */ > + if (!(bitmap= (my_bitmap_map*) thd->alloc(head->s->column_bitmap_size))) > { > column_bitmap.bitmap= 0; > *create_error= 1; > @@ -1923,7 +1924,6 @@ void QUICK_RANGE_SELECT::range_end() > } > delete_dynamic(&ranges); /* ranges are allocated in alloc */ > free_root(&alloc,MYF(0)); > - my_free(column_bitmap.bitmap); > } > my_free(mrr_buf_desc); > DBUG_VOID_RETURN; > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1