- developers - lists.mariadb.org

[Maria-developers] Proposal accepted for GSoc'15
by sriram patil 08 May '15

08 May '15

Hi All, I am Sriram from IIIT Hyderabad, India. I am a Masters' student here. I have worked with MariaDB in GSoC'14 with Alexander Barkov. I had great time hacking on MariaDB last year, so, here I am again. :) This year I will be working on MaxScale filters with Markus Makela. The project title is "MaxScale filter to capture incoming operations for consumption in external sources". (MXS-2) I am excited to get started. Hoping to have a great summer this year as well. :) Thanks, Sriram Patil

2 2

Re: [Maria-developers] [Commits] 313a970: MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover
by Sergei Golubchik 07 May '15

07 May '15

Hi, Sergey! On Apr 08, svoj(a)mariadb.org wrote: > revision-id: 313a970cbe9ac523b0584d293e40bff66d4fbafc > parent(s): 7d9e94e2e6c32b906d1d8469e58bc04b8da1c121 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-08 10:55:51 +0400 > message: > > MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover > table > > Performance schema discovery fails if connection has no active database set. > > This happened due to restriction in SQL parser: table name with no database name > is ambiguous in such case. > > Fixed by temporary substitution of default database with being discovered table > database. ok to push Regards, Sergei

1 0

[Maria-developers] MDEV-7807 information_schema.processlist truncates queries with binary strings
by Alexander Barkov 07 May '15

07 May '15

Hi Sergei, Please review the patch for: MDEV-7807 information_schema.processlist truncates queries with binary strings The patch is for 10.1, as agreed with the reporter. Previously in 10.1 we fixed binary->string conversion behaviour not to truncate on bad bytes, and replace bad bytes to question marks instead. That fixed half of the problem reported. This patch adds a new new column "PROCESSLIST.INFO_BINARY blob". Thanks.

2 1

Re: [Maria-developers] [Commits] 93e746a: MDEV-7793 - Race condition between XA COMMIT/ROLLBACK and disconnect
by Sergei Golubchik 07 May '15

07 May '15

Hi, Sergey! On Mar 17, svoj(a)mariadb.org wrote: > revision-id: 93e746afb2d1a23cb933291ad736a20858b5ac3e > parent(s): ccc7297fe94af1129c717f91d31fa075d54a0371 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-03-17 19:49:04 +0400 > message: > > MDEV-7793 - Race condition between XA COMMIT/ROLLBACK and disconnect > > XA COMMIT/ROLLBACK of XA transaction owned by different thread may access > freed memory if that thread disconnects at the same time. > > Also concurrent XA COMMIT/ROLLBACK of recovered XA transaction were not > serialized properly. > > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index 3071ba6..f18231d 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -5355,7 +5378,7 @@ bool xid_cache_insert(THD *thd, XID_STATE *xid_state) > switch (res) > { > case 0: > - xid_state->xid_cache_element->mark_initialized(); > + xid_state->xid_cache_element->set(XID_cache_element::ACQUIRED); Why not mark_acquired() here? Can you be sure that no other thread has already acquired this xid_cache_element after you've inserted it? > break; > case 1: > my_error(ER_XAER_DUPID, MYF(0)); Regards, Sergei

2 2

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

[Maria-developers] [GSoC 2015] Accepted Student- Self Introduction
by Delveri chick 30 Apr '15

30 Apr '15

Hello everyone ! I am Delveri Chick, a junior software engineering student from Cameroon. I have been accepted into GSoC 2015 to hack on project titled : Improved Temporary Tables. Here <http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/…> is my GSoC proposal. Sergei Golubchik will be mentoring me for this project. I am really excited to spend my summer hacking on MariaDB, and hoping to learn a lot of things from the developer community. Thanks. Delveri

2 1

Re: [Maria-developers] [Commits] 13ecde8: Fix compiler warnings.
by Vicențiu Ciorbaru 30 Apr '15

30 Apr '15

Hi Jan! I have one concern with this patch. See below: On Thu, 30 Apr 2015 at 11:45 Jan Lindström <jan.lindstrom(a)mariadb.com> wrote: > revision-id: 13ecde851f08a7952f774707b19734f351bb6598 > parent(s): 5027e0b035f96e2583eff2d1ac71c7c44a093ac8 > committer: Jan Lindström > branch nick: 10.0-git > timestamp: 2015-04-30 11:44:34 +0300 > message: > > Fix compiler warnings. > > --- > storage/innobase/sync/sync0sync.cc | 27 +++++++++++++-------------- > storage/xtradb/sync/sync0sync.cc | 27 +++++++++++++-------------- > 2 files changed, 26 insertions(+), 28 deletions(-) > > diff --git a/storage/innobase/sync/sync0sync.cc > b/storage/innobase/sync/sync0sync.cc > index 121f8e9..78d86f3 100644 > --- a/storage/innobase/sync/sync0sync.cc > +++ b/storage/innobase/sync/sync0sync.cc > @@ -862,10 +862,10 @@ sync_thread_levels_g( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > I think this here has to be arr->at(i), or &(*arr)[i]. Doing &arr[i] will actually get the i'th std::vector<> which does not exist, since arr is a pointer to only one std::vector<>. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level <= limit) { > if (warn) { > @@ -897,10 +897,10 @@ sync_thread_levels_contain( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -944,10 +944,10 @@ sync_thread_levels_contains( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -993,10 +993,10 @@ sync_thread_levels_nonempty_gen( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!dict_mutex_allowed > @@ -1053,10 +1053,10 @@ sync_thread_levels_nonempty_trx( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!has_search_latch > @@ -1331,7 +1331,7 @@ sync_thread_add_level( > > sync_level.latch = latch; > sync_level.level = level; > - array->elems.push_back(sync_level); > + array->push_back(sync_level); > > mutex_exit(&sync_thread_mutex); > } > @@ -1377,14 +1377,14 @@ sync_thread_reset_level( > > array = thread_slot->levels; > - for (std::vector<sync_level_t>::iterator it = array->elems.begin(); > it != array->elems.end(); ++it) { > + for (std::vector<sync_level_t>::iterator it = array->begin(); it > != array->end(); ++it) { > sync_level_t level = *it; > > if (level.latch != latch) { > continue; > } > > - array->elems.erase(it); > + array->erase(it); > mutex_exit(&sync_thread_mutex); > return(TRUE); > } > @@ -1471,7 +1471,6 @@ sync_thread_level_arrays_free(void) > > /* If this slot was allocated then free the slot memory > too. */ > if (slot->levels != NULL) { > - > slot->levels->elems.erase(slot->levels->elems.begin(),slot->levels->elems.end()); > delete slot->levels; > } > } > diff --git a/storage/xtradb/sync/sync0sync.cc > b/storage/xtradb/sync/sync0sync.cc > index d0e3b71..9dcdd9c 100644 > --- a/storage/xtradb/sync/sync0sync.cc > +++ b/storage/xtradb/sync/sync0sync.cc > @@ -970,10 +970,10 @@ sync_thread_levels_g( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level <= limit) { > if (warn) { > @@ -1005,10 +1005,10 @@ sync_thread_levels_contain( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -1052,10 +1052,10 @@ sync_thread_levels_contains( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -1101,10 +1101,10 @@ sync_thread_levels_nonempty_gen( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!dict_mutex_allowed > @@ -1161,10 +1161,10 @@ sync_thread_levels_nonempty_trx( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!has_search_latch > @@ -1456,7 +1456,7 @@ sync_thread_add_level( > > sync_level.latch = latch; > sync_level.level = level; > - array->elems.push_back(sync_level); > + array->push_back(sync_level); > > mutex_exit(&sync_thread_mutex); > } > @@ -1502,14 +1502,14 @@ sync_thread_reset_level( > > array = thread_slot->levels; > > - for (std::vector<sync_level_t>::iterator it = > array->elems.begin(); it != array->elems.end(); ++it) { > + for (std::vector<sync_level_t>::iterator it = array->begin(); it > != array->end(); ++it) { > sync_level_t level = *it; > > if (level.latch != latch) { > continue; > } > > - array->elems.erase(it); > + array->erase(it); > mutex_exit(&sync_thread_mutex); > return(TRUE); > } > @@ -1597,7 +1597,6 @@ sync_thread_level_arrays_free(void) > > /* If this slot was allocated then free the slot memory > too. */ > if (slot->levels != NULL) { > - > slot->levels->elems.erase(slot->levels->elems.begin(),slot->levels->elems.end()); > delete slot->levels; > } > } >

1 0