- developers - lists.mariadb.org

[Maria-developers] Different results from UNION and UNION DISTINCT
by Pantelis Theodosiou 21 Jun '16

21 Jun '16

According to this post at Stack Overflow, MariaDB 10.1.10 gives wrong results (duplicate rows) for UNION DISTINCT while the UNION version gives correct ones. (notice the comment: http://dba.stackexchange.com/questions/141799/select-distinct-values-of-two… ) The query in question is very simple: SELECT a AS result FROM tableXUNION DISTINCTSELECT b FROM tableX ; I couldn't find a related bug in the MDEV. Is this a known (or fixed) issue or should I go and add a bug report/ Pantelis Theodosiou

2 1

Re: [Maria-developers] 13f13b7: MDEV-5973: MySQL Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE
by Sergei Golubchik 21 Jun '16

21 Jun '16

Hi, Oleksandr! On Jun 21, Oleksandr Byelkin wrote: > revision-id: 13f13b7b2bede46c90772a105a502c33fe93f4d1 (mariadb-10.0.25-11-g13f13b7) > parent(s): 70ad689b11bfbd8a30a777f4893a5384628c00e7 > committer: Oleksandr Byelkin > timestamp: 2016-06-21 18:37:22 +0200 > message: > > MDEV-5973: MySQL Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE > > Condition in processing IGNORE clause for UPDATE & multi-table UPDATE made the same. ok to push, thanks! Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MDEV-9524 Cannot load from mysql.event when sql_mode is set to PAD_CHAR_TO_FULL_LENGTH
by Alexander Barkov 21 Jun '16

21 Jun '16

Hello Sergei, Please review a patch for mdev-9524. Thanks.

2 3

Re: [Maria-developers] 9c253ae: MDEV-8636: REVOKE ALL PRIVILEGES, GRANT OPTION FROM CURRENT_ROLE breaks replication
by Sergei Golubchik 21 Jun '16

21 Jun '16

Hi, Vicentiu! On Jun 20, Vicentiu wrote: > revision-id: 9c253aeafdde8331b8d6f7ed11f1209ab4ce1d5b (mariadb-10.0.25-14-g9c253ae) > parent(s): 9301d5148d68ea7ae89918b87175c374028bfc5d > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2016-06-20 23:43:01 +0300 > message: > > MDEV-8636: REVOKE ALL PRIVILEGES, GRANT OPTION FROM CURRENT_ROLE breaks replication it's 8638, not 8636 > Fix the replication failure caused by incorect initialization of > THD::invoker_host && THD::invoker_user. > > Breakdown of the failure is this: > Query_log_event::host and Query_log_event::user can have their > LEX_STRING's set to length 0, but the actual str member points to > garbage. Code afterwards copies Query_log_event::host and user to > THD::invoker_host and THD::invoker_user. > Calling code for these members expects both members to be initialized. > Eg. the str member be a NULL terminated string and length have > appropriate size. > > diff --git a/sql/log_event.cc b/sql/log_event.cc > index 93704e7..4facd4f 100644 > --- a/sql/log_event.cc > +++ b/sql/log_event.cc > @@ -3631,10 +3631,8 @@ Query_log_event::Query_log_event(const char* buf, uint event_len, > if (time_zone_len) > copy_str_and_move(&time_zone_str, &start, time_zone_len); > > - if (user.length > 0) > - copy_str_and_move((const char **)&(user.str), &start, user.length); > - if (host.length > 0) > - copy_str_and_move((const char **)&(host.str), &start, host.length); > + copy_str_and_move((const char **)&(user.str), &start, user.length); > + copy_str_and_move((const char **)&(host.str), &start, host.length); I think the bug is that user.str or host.str may point to some garbage. I'd suggest the following fix instead: --- a/sql/log_event.cc +++ b/sql/log_event.cc @@ -3548,17 +3548,12 @@ Query_log_event::Query_log_event(const char* buf, uint e break; case Q_INVOKER: { - CHECK_SPACE(pos, end, 1); - user.length= *pos++; - CHECK_SPACE(pos, end, user.length); - user.str= (char *)pos; - pos+= user.length; - - CHECK_SPACE(pos, end, 1); - host.length= *pos++; - CHECK_SPACE(pos, end, host.length); - host.str= (char *)pos; - pos+= host.length; + if (get_str_len_and_pointer(&pos, &user.str, &user.length, end) || + get_str_len_and_pointer(&pos, &host.str. &host.length, end)) + { + query= 0; + DBUG_VOID_RETURN; + } break; } case Q_HRNOW: Ok ot push if you agree (and it works :) Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] dd32ca1: MDEV-5973: MySQL Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE
by Sergei Golubchik 21 Jun '16

21 Jun '16

Hi, Oleksandr! On Jun 20, Oleksandr Byelkin wrote: > revision-id: dd32ca182246fccc7ba8d7c612af3ddd27fbf4af (mariadb-10.0.25-11-gdd32ca1) > parent(s): 70ad689b11bfbd8a30a777f4893a5384628c00e7 > committer: Oleksandr Byelkin > timestamp: 2016-06-20 14:35:58 +0200 > message: > > MDEV-5973: MySQL Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE > > Condition in processing IGNORE clause for UPDATE & multi-table UPDATE made the same. > > diff --git a/mysql-test/r/multi_update.result b/mysql-test/r/multi_update.result > index 688184f..9e47fe2 100644 > --- a/mysql-test/r/multi_update.result > +++ b/mysql-test/r/multi_update.result > @@ -1039,4 +1039,24 @@ f1 f2 > 1 97 > DROP TABLE t1, t2; > DROP VIEW v1; > +# > +# MDEV-5973: MySQL Bug#11757486:49539: NON-DESCRIPTIVE ERR (ERROR 0 > +# FROM STORAGE ENGINE) WITH MULTI-TABLE UPDATE > +# > +CREATE TABLE table_11757486 (field1 tinyint) ENGINE=INNODB; > +INSERT INTO table_11757486 VALUES (0),(0); > +SET SESSION SQL_MODE='STRICT_ALL_TABLES'; > +UPDATE IGNORE (SELECT 128 as col1) x, table_11757486 SET field1=x.col1; Please add same tests in a single-table update version: UPDATE IGNORE table_11757486 SET field1=128; all three UPDATEs should be in both single and multi-table versions. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] b865428: MDEV-10258 - Valgrind warnings in buildbot after a set of mroonga tests
by Sergei Golubchik 21 Jun '16

21 Jun '16

Hi, Sergey! On Jun 20, Sergey Vojtovich wrote: > revision-id: b865428f1373cad45c2d92f7e659e09647bdbb31 (mariadb-10.0.25-13-gb865428) > parent(s): 99c8fb8d971c8e882b4f12296e322504f6b847cf > committer: Sergey Vojtovich > timestamp: 2016-06-20 13:54:19 +0400 > message: > > MDEV-10258 - Valgrind warnings in buildbot after a set of mroonga tests > > Fixed memory leak when mroonga fails to open index files. > Memory leak was detected by valgrind when running > mroonga/storage.repair_table_no_index_file. ok to push Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] 511bd2c: MDEV-10216: Assertion `strcmp(share->unique_file_name, filename) ||
by Sergey Vojtovich 20 Jun '16

20 Jun '16

Hi Nirbhay, last_version of MyISAM is used for debugging only and has no functional effect. last_version of Aria has some functional effect. Effect of HA_EXTRA_PREPARE_FOR_RENAME for MyISAM is flush key blocks and reset last_version. Effect of HA_EXTRA_PREPARE_FOR_RENAME for Aria is more complex. Other engines ignore HA_EXTRA_PREPARE_FOR_RENAME. I don't completely understand why "ALTER TABLE ... RENAME TO ..." has to copy data between tables. But it is probably subject of another bug (or even task). copy_data_between_tables() seem to be the only function that does HA_EXTRA_PREPARE_FOR_RENAME for temporary table (intermediate in this case). I don't think the above HA_EXTRA_PREPARE_FOR_RENAME is reasonable for MyISAM. There's no point in resetting last_version and flushing key blocks, since we're going to reuse this itermediate table anyway. I don't think the above can be reasonable for any engine. Said the above, I'd vote to remove this call. But please check with some Aria expert. Your fix is mostly alright, but I guess we shouldn't reset last_version in case of HA_EXTRA_PREPARE_FOR_DROP. Regards, Sergey On Wed, Jun 15, 2016 at 08:57:06AM -0400, Nirbhay Choubey wrote: > revision-id: 511bd2ca3269bc7bf80e30cceeab534f7f3e5666 (mariadb-10.2.0-83-g511bd2c) > parent(s): b2ae32aafdd2787ad456f38833f630182ded25e8 > author: Nirbhay Choubey > committer: Nirbhay Choubey > timestamp: 2016-06-15 08:57:04 -0400 > message: > > MDEV-10216: Assertion `strcmp(share->unique_file_name,filename) || > > .. share->last_version' failed in myisam/mi_open.c:67: test_if_reopen > > During the RENAME operation since the renamed temporary table is also > opened and added to myisam_open_list/maria_open_list, resetting the > last_version at the end of operation (HA_EXTRA_PREPARE_FOR_RENAME) > will cause an assertion failure when a subsequent query tries to open > an additional temporary table instance and thus attempts to reuse it > from the open table list. > > Fixed by not resetting share->last_version for temporary tables so that > the share gets reused when needed. > > --- > mysql-test/r/reopen_temp_table.result | 18 ++++++++++++++++++ > mysql-test/t/reopen_temp_table.test | 16 ++++++++++++++++ > storage/maria/ma_extra.c | 7 ++++++- > storage/myisam/mi_extra.c | 7 ++++++- > 4 files changed, 46 insertions(+), 2 deletions(-) > > diff --git a/mysql-test/r/reopen_temp_table.result b/mysql-test/r/reopen_temp_table.result > index 08affaa..e63a21e 100644 > --- a/mysql-test/r/reopen_temp_table.result > +++ b/mysql-test/r/reopen_temp_table.result > @@ -164,5 +164,23 @@ SELECT COUNT(*)=4 FROM t6; > COUNT(*)=4 > 1 > DROP TABLE t5, t6; > +# > +# MDEV-10216: Assertion `strcmp(share->unique_file_name,filename) || > +# share->last_version' failed in myisam/mi_open.c:67: test_if_reopen > +# > +CREATE TEMPORARY TABLE t7 (i INT) ENGINE=MYISAM; > +INSERT INTO t7 VALUES(1); > +ALTER TABLE t7 RENAME TO t; > +SELECT * FROM t a, t b; > +i i > +1 1 > +DROP TABLE t; > +CREATE TEMPORARY TABLE t7 (i INT) ENGINE=ARIA; > +INSERT INTO t7 VALUES(1); > +ALTER TABLE t7 RENAME TO t; > +SELECT * FROM t a, t b; > +i i > +1 1 > +DROP TABLE t; > # Cleanup > DROP DATABASE temp_db; > diff --git a/mysql-test/t/reopen_temp_table.test b/mysql-test/t/reopen_temp_table.test > index 98de983..83a5bbc 100644 > --- a/mysql-test/t/reopen_temp_table.test > +++ b/mysql-test/t/reopen_temp_table.test > @@ -159,5 +159,21 @@ SELECT COUNT(*)=6 FROM t5; > SELECT COUNT(*)=4 FROM t6; > DROP TABLE t5, t6; > > +--echo # > +--echo # MDEV-10216: Assertion `strcmp(share->unique_file_name,filename) || > +--echo # share->last_version' failed in myisam/mi_open.c:67: test_if_reopen > +--echo # > +CREATE TEMPORARY TABLE t7 (i INT) ENGINE=MYISAM; > +INSERT INTO t7 VALUES(1); > +ALTER TABLE t7 RENAME TO t; > +SELECT * FROM t a, t b; > +DROP TABLE t; > + > +CREATE TEMPORARY TABLE t7 (i INT) ENGINE=ARIA; > +INSERT INTO t7 VALUES(1); > +ALTER TABLE t7 RENAME TO t; > +SELECT * FROM t a, t b; > +DROP TABLE t; > + > --echo # Cleanup > DROP DATABASE temp_db; > diff --git a/storage/maria/ma_extra.c b/storage/maria/ma_extra.c > index fd21d28..5b33ad6 100644 > --- a/storage/maria/ma_extra.c > +++ b/storage/maria/ma_extra.c > @@ -399,7 +399,12 @@ int maria_extra(MARIA_HA *info, enum ha_extra_function function, > share->bitmap.changed_not_flushed= 0; > } > /* last_version must be protected by intern_lock; See collect_tables() */ > - share->last_version= 0L; /* Impossible version */ > + /* > + Temporary table has already been added to maria_open_list, so > + lets not reset the last_version. > + */ > + if (!share->temporary) > + share->last_version= 0L; /* Impossible version */ > mysql_mutex_unlock(&share->intern_lock); > break; > } > diff --git a/storage/myisam/mi_extra.c b/storage/myisam/mi_extra.c > index a47c198..bc5705a 100644 > --- a/storage/myisam/mi_extra.c > +++ b/storage/myisam/mi_extra.c > @@ -265,7 +265,12 @@ int mi_extra(MI_INFO *info, enum ha_extra_function function, void *extra_arg) > /* Fall trough */ > case HA_EXTRA_PREPARE_FOR_RENAME: > mysql_mutex_lock(&THR_LOCK_myisam); > - share->last_version= 0L; /* Impossible version */ > + /* > + Temporary table has already been added to myisam_open_list, so > + lets not reset the last_version. > + */ > + if (!share->temporary) > + share->last_version= 0L; /* Impossible version */ > mysql_mutex_lock(&share->intern_lock); > /* Flush pages that we don't need anymore */ > if (flush_key_blocks(share->key_cache, share->kfile, > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

Re: [Maria-developers] 7910c99: MDEV-10043 - main.events_restart fails sporadically in buildbot (crashes upon
by Sergei Golubchik 20 Jun '16

20 Jun '16

Hi, Sergey! On Jun 17, Sergey Vojtovich wrote: > revision-id: 7910c99bd1fa30911225e512997f466cb1b7996d (mariadb-5.5.49-51-g7910c99) > parent(s): 7ff86b49912df5de7b5a8b9c9134e72134b7ba5c > committer: Sergey Vojtovich > timestamp: 2016-06-17 18:54:11 +0400 > message: > > MDEV-10043 - main.events_restart fails sporadically in buildbot (crashes upon > shutdown) > > There was race condition between shutdown thread and event worker threads. > > Shutdown thread waits for thread_count to become 0 in close_connections(). It > may happen so that event worker thread was started but didn't increment > thread_count by this time. In this case shutdown thread may miss wait for this > working thread and continue deinitialization. Worker thread in turn may continue > execution and crash on deinitialized data. > > Fixed by incrementing thread_count before thread is actually created like it is > done for connection threads. > > Also let event scheduler not to inc/dec running threads counter for symmetry > with other "service" threads. ok to push. I'll have a questionable pleasure of merging it into 10.2 :) (it conflicts with 562c1df). Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MDEV-10020 InnoDB NOT IN Query Crash When One Item Is NULL
by Alexander Barkov 20 Jun '16

20 Jun '16

Hi Sergei, Please review a patch for mdev-10020. The problem was that the loop in get_func_mm_tree() accessed an improperly initialized instance of String, which is a bzero'ed part of the in_vector::base array. Strings in in_vector::base are initialized in Item_func_in::fix_length_and_dec(): in in_vector::in_vector() using sql_calloc, rather than a String constructor, so its str_charset member of this String is NULL. Strings in in_vector::base are later initialized in Item_func_in::fix_length_and_dec(), using array->set(), in this code: uint j=0; for (uint i=1 ; i < arg_count ; i++) { array->set(j,args[i]); if (!args[i]->null_value) // Skip NULL values j++; else have_null= 1; } if ((array->used_count= j)) array->sort(); NULLs are not taken into account, so array->used_count can be smaller than array->count. This patch fixes the loop in opt_range.cc, in get_func_mm_tree(), to access only properly initialized elements in in_vector::base, preventing access to its bzero'ed non-initialized tail. Thanks.

2 1

Re: [Maria-developers] fa129a7: MDEV-9728 - Hard crash in metadata_lock_info
by Sergei Golubchik 20 Jun '16

20 Jun '16

Hi, Sergey! Looks ok to push, thanks! On Jun 17, Sergey Vojtovich wrote: > revision-id: fa129a7d22656eff9a7d1fb137d22976e0f0cec1 (mariadb-10.0.25-7-gfa129a7) > parent(s): 56ec3bdebd4a17ff59a487a988069f77bfc69aab > committer: Sergey Vojtovich > timestamp: 2016-06-17 12:52:35 +0400 > message: > > MDEV-9728 - Hard crash in metadata_lock_info > > metadata_lock_info plugin called MDL_context::find_ticket() to obtain lock > duration, which in turn iterates foreign thread private lists. These lists > can be updated by owner thread without protection. > > Fixed by iterating threads (instead of MDL locks and tickets) and obtaining > data through APC. > > Also fixed mdl_iterate_lock() to initialize iterator under prlock protection. > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0