October 2021 - developers - lists.mariadb.org

Re: [Maria-developers] 5c4db10d6ff: MDEV-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL)
by Sergei Golubchik 24 Oct '21

24 Oct '21

Hi, Jan! On Oct 24, Jan LindstrÃ¶m wrote: > revision-id: 5c4db10d6ff (mariadb-10.3.31-58-g5c4db10d6ff) > parent(s): f9b856b0525 > author: Jan Lindström > committer: Jan Lindström > timestamp: 2021-10-22 07:23:14 +0300 > message: > > MDEV-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL) > > Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" > > This reverts commit 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6. This was incorrectly reverted. 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6 didn't apply to 10.3 verbatim, there were some merge related changes. To revert it properly you need to look at affected files before the corresponding 10.2->10.3 merge. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] dfa33fb309d: MDEV-26664 Store UUIDs in a more efficient manner
by Sergei Golubchik 22 Oct '21

22 Oct '21

Hi, Alexander! On Oct 19, Alexander Barkov wrote: > revision-id: dfa33fb309d (mariadb-10.6.1-84-gdfa33fb309d) > parent(s): 5cfb31854a4 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2021-10-19 13:27:19 +0400 > message: > > MDEV-26664 Store UUIDs in a more efficient manner > > UUID values > > llllllll-mmmm-Vhhh-vsss-nnnnnnnnnnnn > > are now stored as > > nnnnnnnnnnnn-vsss-Vhhh-mmmm-llllllll > > inside the record: > > - the groups (segments separated by dash) are reordered right-to-left. > - the bytes inside the groups are not reordered (stored as before, > in big-endian format). > > This provides a better sorting order: the earlier UUID was generated, > the higher it appears in the ORDER BY output. > > Also, this change enables a good key prefix compression, > because the constant part is now in the beginning, while > the non-constant part (the timestamp) is in the end. > > diff --git a/plugin/type_uuid/mysql-test/type_uuid/type_uuid.result b/plugin/type_uuid/mysql-test/type_uuid/type_uuid.result > index 6a08ffe8c23..6e2e1cc87ef 100644 > --- a/plugin/type_uuid/mysql-test/type_uuid/type_uuid.result > +++ b/plugin/type_uuid/mysql-test/type_uuid/type_uuid.result > @@ -596,10 +596,10 @@ INSERT INTO t1 VALUES (CAST(CONCAT('2','0000000-0000-0000-0000-000000000003') AS > SELECT * FROM t1 ORDER BY a; > a > 10000000-0000-0000-0000-000000000001 > -10000000-0000-0000-0000-000000000002 > -10000000-0000-0000-0000-000000000003 > 20000000-0000-0000-0000-000000000001 > +10000000-0000-0000-0000-000000000002 > 20000000-0000-0000-0000-000000000002 > +10000000-0000-0000-0000-000000000003 > 20000000-0000-0000-0000-000000000003 please, add a test for `ORDER BY CONCAT(a)` just to test the lexicographical ordering of UUIDs. Or may be `ORDER BY HEX(a)` ? Or `UNHEX` ? Whatever the recommended approach should be. > DROP TABLE t1; > # > diff --git a/plugin/type_uuid/mysql-test/type_uuid/type_uuid_memory.result b/plugin/type_uuid/mysql-test/type_uuid/type_uuid_memory.result > index 42bb74d4b01..eb7a51895b9 100644 > --- a/plugin/type_uuid/mysql-test/type_uuid/type_uuid_memory.result > +++ b/plugin/type_uuid/mysql-test/type_uuid/type_uuid_memory.result > @@ -25,7 +25,7 @@ a > 00000000-0000-0000-0000-0000000000ff > EXPLAIN SELECT * FROM t1 WHERE a='00000000-0000-0000-0000-0000000000ff'; > id select_type table type possible_keys key key_len ref rows Extra > -1 SIMPLE t1 ref a a 17 const 2 Using where > +1 SIMPLE t1 ref a a 17 const 4 Using where why? > diff --git a/plugin/type_uuid/sql_type_uuid.h b/plugin/type_uuid/sql_type_uuid.h > index 9076c874e98..be9fea8ebc9 100644 > --- a/plugin/type_uuid/sql_type_uuid.h > +++ b/plugin/type_uuid/sql_type_uuid.h > @@ -24,8 +24,162 @@ class UUID: public FixedBinTypeStorage<MY_UUID_SIZE, MY_UUID_STRING_LENGTH> ... > + // Compare two in-memory values > + static int cmp(const LEX_CSTRING &a, const LEX_CSTRING &b) > + { this is way more LoC that I would've used. but ok, it's your code and it's a plugin, so as you like > diff --git a/sql/sql_string.h b/sql/sql_string.h > index fe57c8153bb..795f80c3e08 100644 > --- a/sql/sql_string.h > +++ b/sql/sql_string.h > @@ -484,6 +484,11 @@ class Binary_string: public Sql_alloc > if (str.Alloced_length) > Alloced_length= (uint32) (str.Alloced_length - offset); > } > + LEX_CSTRING to_lex_cstring() const > + { > + LEX_CSTRING tmp= {Ptr, str_length}; > + return tmp; > + } > inline LEX_CSTRING *get_value(LEX_CSTRING *res) may be you could remove get_value()? In a separate commit. the name is quite bad and the method makes rather little sense, especially if there's to_lex_cstring() now. > { > res->str= Ptr; > diff --git a/sql/sql_type_fixedbin.h b/sql/sql_type_fixedbin.h > index c6e3d20bcfa..5141cb9fad4 100644 > --- a/sql/sql_type_fixedbin.h > +++ b/sql/sql_type_fixedbin.h > @@ -154,18 +160,13 @@ class FixedBinTypeBundle > FbtImpl::max_char_length()+1)); > return false; > } > - int cmp(const char *str, size_t length) const > - { > - DBUG_ASSERT(length == sizeof(m_buffer)); > - return memcmp(m_buffer, str, length); > - } > int cmp(const Binary_string &other) const what is this one used for? > { > - return cmp(other.ptr(), other.length()); > + return FbtImpl::cmp(FbtImpl::to_lex_cstring(), other.to_lex_cstring()); > } > int cmp(const Fbt &other) const > { > - return memcmp(m_buffer, other.m_buffer, sizeof(m_buffer)); > + return FbtImpl::cmp(FbtImpl::to_lex_cstring(), other.to_lex_cstring()); > } > }; > > diff --git a/sql/sql_type_fixedbin_storage.h b/sql/sql_type_fixedbin_storage.h > index 0e8ac81ab59..6e18335bd4c 100644 > --- a/sql/sql_type_fixedbin_storage.h > +++ b/sql/sql_type_fixedbin_storage.h > @@ -21,6 +21,38 @@ > format and their own (variable size) canonical string representation. > > Examples are INET6 and UUID types. > + > + The MariaDB server uses three binary representations of a data type: > + > + 1. In-memory binary representation (user visible) > + This representation: > + - can be used in INSERT..VALUES (X'AABBCC') > + - can be used in WHERE conditions: WHERE c1=X'AABBCC' > + - is returned by CAST(x AS BINARY(N)) > + - is returned by Field::val_native() and Item::val_native() > + > + 2. In-record binary representation (user invisible) > + This representation: > + - is used in records (is pointed by Field::ptr) > + - must be comparable by memcmp() > + > + 3. Binlog binary (row) representation > + Usually, for string data types the binlog representation > + is based on the in-record representation with trailing byte compression: > + - trailing space compression for text string data types > + - trailing zero compression for binary string data types > + > + We have to have separate in-memory and in-record representations > + because we use HA_KEYTYPE_BINARY for indexing. The engine API > + does not have a way to pass a comparison function as a parameter. > + > + The default implementation below assumes that: > + - the in-memory and in-record representations are equal > + - the binlog representation is compatible with BINARY(N) > + This is OK for simple data types, like INET6. > + > + Data type implementations that need different representations > + can override the default implementation (like e.g. UUID does). > */ thanks, this is very good > > /***********************************************************************/ > @@ -64,5 +137,37 @@ class FixedBinTypeStorage > return true; > } > > + static ulong KEY_pack_flags(uint column_nr) > + { > + /* > + Return zero by default. A particular data type can override > + this method return some flags, e.g. HA_PACK_KEY to enable > + key prefix compression. what if you change it later, will it make old tables corrupted? > + */ > + return 0; > + } Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 3

Re: [Maria-developers] 4b164f176e6: MDEV-25114 Crash: WSREP: invalid state ROLLED_BACK (FATAL)
by Sergei Golubchik 21 Oct '21

21 Oct '21

Hi, Seppo, Jan! Note, this is 10.2 patch below. > commit 4b164f176e6 > Author: Seppo Jaakola <seppo.jaakola(a)galeracluster.com> > Date: Wed Sep 15 09:16:44 2021 +0300 > > MDEV-25114 Crash: WSREP: invalid state ROLLED_BACK (FATAL) I think this should say MDEV-23328 Server hang due to Galera lock conflict resolution it'd be easier to understand the commit comment and code changes if it'll refer to the correct problem it is fixing. The fix for MDEV-25114 was the previous commit, the one that This reverts commit 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6 it should have MDEV-25114 in the commit comment. > > This patch is the plan D variant for fixing potetial mutex locking "potential" > order exercised by BF aborting and KILL command execution. > > In this approach, KILL command is replicated as TOI operation. > This guarantees total isolation for the KILL command execution > in the first node: there is no concurrent replication applying > and no concurrent DDL executing. Therefore there is no risk of > BF aborting to happen in parallel with KILL command execution > either. Potential mutex deadlocks between the different mutex > access paths with KILL command execution and BF aborting cannot > therefore happen. > > TOI replication is used, in this approach, purely as means > to provide isolated KILL command execution in the first node. > KILL command should not (and must not) be applied in secondary > nodes. In this patch, we make this sure by skipping KILL > execution in secondary nodes, in applying phase, where we > bail out if applier thread is trying to execute KILL command. > This is effective, but skipping the applying of KILL command > could happen much earlier as well. I like the idea of using TOI apparatus to provide total isolation for KILL. Actually replicating it to nodes is kind of crude, it'd be more elegant not to replicate at all. But it'll do. > > This patch also fixes mutex locking order and unprotected > THD member accesses on bf aborting case. We try to hold > THD::LOCK_thd_data during bf aborting. Only case where it > is not possible is at wsrep_abort_transaction before > call wsrep_innobase_kill_one_trx where we take InnoDB > mutexes first and then THD::LOCK_thd_data. > > This will also fix possible race condition during > close_connection and while wsrep is disconnecting > connections. > > Added wsrep_bf_kill_debug test case > > Reviewed-by: Jan Lindström <jan.lindstrom(a)mariadb.com> > > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index 5ada018e540..05ec9a1c369 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -1804,11 +1804,11 @@ void THD::awake(killed_state state_to_set) > the Vio might be disassociated concurrently. > */ > > -void THD::disconnect() > +void THD::disconnect_mutexed() should be disconnect_no_mutex, cf. awake_no_mutex, set_killed_no_mutex. > { > Vio *vio= NULL; > > - mysql_mutex_lock(&LOCK_thd_data); > + mysql_mutex_assert_owner(&LOCK_thd_data); > > set_killed(KILL_CONNECTION); > > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 3e1f248b082..2bec9c6b6cd 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -9069,6 +9069,18 @@ static > void sql_kill(THD *thd, longlong id, killed_state state, killed_type type) > { > uint error; > +#ifdef WITH_WSREP > + if (WSREP(thd)) > + { > + WSREP_DEBUG("sql_kill called"); > + if (thd->wsrep_applier) > + { > + WSREP_DEBUG("KILL in applying, bailing out here"); > + return; > + } > + WSREP_TO_ISOLATION_BEGIN(WSREP_MYSQL_DB, NULL, NULL) when can it fail and jump to wsrep_error_label? under what conditions? > + } > +#endif /* WITH_WSREP */ > if (!(error= kill_one_thread(thd, id, state, type))) > { > if (!thd->killed) > diff --git a/sql/wsrep_mysqld.cc b/sql/wsrep_mysqld.cc > index e60100e2e90..00a6dfe2f8a 100644 > --- a/sql/wsrep_mysqld.cc > +++ b/sql/wsrep_mysqld.cc > @@ -835,13 +835,25 @@ void wsrep_thr_init() > DBUG_VOID_RETURN; > } > > +/* This is wrapper for wsrep_break_lock in thr_lock.c */ > +static int wsrep_thr_abort_thd(void *bf_thd_ptr, void *victim_thd_ptr, my_bool signal) > +{ > + THD* victim_thd= (THD *) victim_thd_ptr; > + /* We need to lock THD::LOCK_thd_data to protect victim > + from concurrent usage or disconnect or delete. */ How do you know victim_thd wasn't deleted before you locked LOCK_thd_data below? > + mysql_mutex_lock(&victim_thd->LOCK_thd_data); > + int res= wsrep_abort_thd(bf_thd_ptr, victim_thd_ptr, signal); > + mysql_mutex_unlock(&victim_thd->LOCK_thd_data); > + return res; > +} > > diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc > index 1f666f19d8a..921b8282e45 100644 > --- a/storage/innobase/handler/ha_innodb.cc > +++ b/storage/innobase/handler/ha_innodb.cc > @@ -19739,27 +19739,65 @@ wsrep_abort_transaction( > { > DBUG_ENTER("wsrep_abort_transaction"); > > + ut_ad(bf_thd); > + ut_ad(victim_thd); > trx_t* victim_trx= thd_to_trx(victim_thd); > - trx_t* bf_trx = (bf_thd) ? thd_to_trx(bf_thd) : NULL; > + trx_t* bf_trx= thd_to_trx(bf_thd); > > > if (victim_trx) { > + wsrep_thd_UNLOCK(victim_thd); what keeps victim_trx from disappearing here? > lock_mutex_enter(); > trx_mutex_enter(victim_trx); > wsrep_innobase_kill_one_trx(bf_thd, bf_trx, victim_trx, signal); > lock_mutex_exit(); > trx_mutex_exit(victim_trx); > wsrep_srv_conc_cancel_wait(victim_trx); > + wsrep_thd_LOCK(victim_thd); > DBUG_VOID_RETURN; > } else { > - wsrep_thd_LOCK(victim_thd); > wsrep_thd_set_conflict_state(victim_thd, MUST_ABORT); > - wsrep_thd_UNLOCK(victim_thd); > wsrep_thd_awake(victim_thd, signal); > } Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 20

Re: [Maria-developers] 688ad5ed67f: MDEV-26830: Wrong ROW_NUMBER in diagnostics upon INSERT IGNORE with CHECK violation
by Sergei Golubchik 18 Oct '21

18 Oct '21

Hi, Rucha! On Oct 18, Rucha Deodhar wrote: > revision-id: 688ad5ed67f (mariadb-10.6.1-138-g688ad5ed67f) > parent(s): c27f04ede5a > author: Rucha Deodhar > committer: Rucha Deodhar > timestamp: 2021-10-18 13:40:56 +0530 > message: > > MDEV-26830: Wrong ROW_NUMBER in diagnostics upon INSERT IGNORE with > CHECK violation > > Analysis: When there is constraint fail we return non-zero value for > view_check_option(). So we continue the loop which doesn't increment the > counter because it increments at the end of the loop. > Fix: Increment m_current_row_for_warning() at the beginning of loop. This > will also fix similar bugs if any, about counter not incrementing > correctly because of continue. > > diff --git a/sql/sql_insert.cc b/sql/sql_insert.cc > index 3dff6722a3d..11289779f7c 100644 > --- a/sql/sql_insert.cc > +++ b/sql/sql_insert.cc > @@ -1007,8 +1007,10 @@ bool mysql_insert(THD *thd, TABLE_LIST *table_list, > goto values_loop_end; > } > > + thd->get_stmt_da()->reset_current_row_for_warning(0); This changes the behavior in array binding case, let's not do it in this commit. Better change the previous reset_current_row_for_warning() to reset to 0, not to 1. The rest is ok. > while ((values= its++)) > { > + thd->get_stmt_da()->inc_current_row_for_warning(); > if (fields.elements || !value_count) > { > /* > @@ -1125,7 +1127,6 @@ bool mysql_insert(THD *thd, TABLE_LIST *table_list, > if (unlikely(error)) > break; > info.accepted_rows++; > - thd->get_stmt_da()->inc_current_row_for_warning(); > } > its.rewind(); > iteration++; > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] a895fce3277: MDEV-26842: MDEV-26842: ROW_NUMBER is not set and differs from the message upon WARN_DATA_TRUNCATED produced by inplace ALTER
by Sergei Golubchik 17 Oct '21

17 Oct '21

Hi, Rucha! On Oct 17, Rucha Deodhar wrote: > revision-id: a895fce3277 (mariadb-10.6.1-138-ga895fce3277) > parent(s): c27f04ede5a > author: Rucha Deodhar > committer: Rucha Deodhar > timestamp: 2021-10-17 17:59:11 +0530 > message: > > MDEV-26842: MDEV-26842: ROW_NUMBER is not set and differs from the message > upon WARN_DATA_TRUNCATED produced by inplace ALTER > > Analysis: When row number is passed as parameter to set_warning() it is only > used for error/warning text but m_current_row_for_warning is not updated. > Hence default value of m_current_row_for_warning is assumed. > Fix: update m_current_row_for_warning when error/warning occurs. > > diff --git a/sql/field.cc b/sql/field.cc > index a5cd595f05b..048798ea509 100644 > --- a/sql/field.cc > +++ b/sql/field.cc > @@ -11086,6 +11086,10 @@ Field::set_warning(Sql_condition::enum_warning_level level, uint code, > will have table == NULL. > */ > THD *thd= get_thd(); > + ulong row_count= current_row ? current_row > + : thd->get_stmt_da()->current_row_for_warning(); > + > + thd->get_stmt_da()->reset_current_row_for_warning(row_count); Isn't it a bit confusing, why do you set current_row_for_warning to its own actual value? May be it'd be clearer to if (current_row) thd->get_stmt_da()->reset_current_row_for_warning(current_row); And also, please, mention either here or in the commit comment that it's for INPLACE alter, where the server cannot know what row has generated the warning, so the value of current_row is supplied by the engine. > if (thd->count_cuted_fields > CHECK_FIELD_EXPRESSION) > { > thd->cuted_fields+= cut_increment; > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 351a0a7d6b7: MDEV-26841: ROW_NUMBER is not set and differs from the message upon ER_WRONG_VALUE_COUNT_ON_ROW for the 1st row
by Sergei Golubchik 17 Oct '21

17 Oct '21

Hi, Rucha! On Oct 17, Rucha Deodhar wrote: > revision-id: 351a0a7d6b7 (mariadb-10.6.1-138-g351a0a7d6b7) > parent(s): c27f04ede5a > author: Rucha Deodhar > committer: Rucha Deodhar > timestamp: 2021-10-17 16:24:47 +0530 > message: > > MDEV-26841: ROW_NUMBER is not set and differs from the message upon > ER_WRONG_VALUE_COUNT_ON_ROW for the 1st row > > diff --git a/sql/sql_insert.cc b/sql/sql_insert.cc > index 3dff6722a3d..9e81c33ff8f 100644 > --- a/sql/sql_insert.cc > +++ b/sql/sql_insert.cc > @@ -229,6 +229,8 @@ static int check_insert_fields(THD *thd, TABLE_LIST *table_list, > } > if (values.elements != table->s->visible_fields) > { > + if (values.elements > table->s->visible_fields) why do you need an if() here? > + thd->get_stmt_da()->inc_current_row_for_warning(); > my_error(ER_WRONG_VALUE_COUNT_ON_ROW, MYF(0), 1L); > DBUG_RETURN(-1); > } Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] fcf2c5fff14: MDEV-26299: Some views force server (and mysqldump) to generate invalid SQL for their definitions
by Sergei Golubchik 16 Oct '21

16 Oct '21

Hi, Oleksandr! On Oct 16, Oleksandr Byelkin wrote: > revision-id: fcf2c5fff14 (mariadb-10.2.40-78-gfcf2c5fff14) > parent(s): d5a15f04f4a > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2021-10-01 14:46:22 +0200 > message: > > MDEV-26299: Some views force server (and mysqldump) to generate invalid SQL for their definitions > > Do not print illegal table field names for non-top-level SELECT list, > they will not be refered in any case but create problem for parsing > of printed result. > > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index ff584e936b7..ebee9c85791 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -25797,6 +25797,11 @@ void st_select_lex::print(THD *thd, String *str, enum_query_type query_type) > > //Item List > bool first= 1; > + /* > + outer_select() can not be used here because it is for name resolution > + and will return NULL at any end of name resolution chain (view/derived) > + */ > + bool top_level= (get_master()->get_master() == 0); > List_iterator_fast<Item> it(item_list); > Item *item; > while ((item= it++)) > @@ -25806,7 +25811,8 @@ void st_select_lex::print(THD *thd, String *str, enum_query_type query_type) > else > str->append(','); > > - if (is_subquery_function() && item->is_autogenerated_name) > + if ((is_subquery_function() && item->is_autogenerated_name) || > + !item->name) Where can item->name be NULL? I thought the either specified by the user or autogenerated, but never NULL. > { > /* > Do not print auto-generated aliases in subqueries. It has no purpose > @@ -25815,7 +25821,26 @@ void st_select_lex::print(THD *thd, String *str, enum_query_type query_type) > item->print(str, query_type); > } > else > - item->print_item_w_name(str, query_type); > + { > + /* > + Despite presence of item->name_length it is incorrect in many cases > + till we start using LEX_STRING for the name. > + */ > + size_t len= strlen(item->name); > + > + /* > + Do not print illegal names (if it is not top level SELECT). > + Top level view checked (and correct name are assigned), > + other cases of top level SELECT are not important, because > + it is not "table field". > + */ > + if (top_level || > + !item->is_autogenerated_name || > + !check_table_name(item->name, len, TRUE)) why check_table_name() if it isn't a table? it's an incorrect check to use for columns. > + item->print_item_w_name(str, query_type); > + else > + item->print(str, query_type); > + } > } > > /* > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 2

Re: [Maria-developers] baaaa971662: MDEV-22883: Assertion `!parse_error || lex.sphead == 0' failed in Table_triggers_list::check_n_load | SIGSEGV in strxmov
by Sergei Golubchik 15 Oct '21

15 Oct '21

Hi, Oleksandr! On Oct 15, Oleksandr Byelkin wrote: > revision-id: baaaa971662 (mariadb-10.2.40-61-gbaaaa971662) > parent(s): dce490e9d4d > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2021-09-19 19:23:49 +0200 > message: > > MDEV-22883: Assertion `!parse_error || lex.sphead == 0' failed in Table_triggers_list::check_n_load | SIGSEGV in strxmov > > Abort execution of SHOW in case of fatal error. Does this patch fixes all test cases from the bug report? There are quite a few. > diff --git a/sql/sql_show.cc b/sql/sql_show.cc > index 721bb053343..105b2719882 100644 > --- a/sql/sql_show.cc > +++ b/sql/sql_show.cc > @@ -4849,7 +4849,8 @@ static int fill_schema_table_from_frm(THD *thd, TABLE *table, > */ > DBUG_ASSERT(thd->open_tables == NULL); > thd->mdl_context.rollback_to_savepoint(open_tables_state_backup->mdl_system_tables_svp); > - thd->clear_error(); > + if (!thd->is_fatal_error) > + thd->clear_error(); Hmm. THD::clear_error() starts with a comment: /** Clear the current error, if any. We do not clear is_fatal_error or is_fatal_sub_stmt_error since we assume this is never called if the fatal error is set. Unfortunately, it doesn't have an assert to go with this, otherwise all these bugs would've probably failed identically and early. Please add DBUG_ASSERT(!is_fatal_error); DBUG_ASSERT(!is_fatal_sub_stmt_error); or something like that to THD::clear_error() > return res; > } > > @@ -5064,7 +5065,7 @@ int get_all_tables(THD *thd, TABLE_LIST *tables, COND *cond) > continue; > } > > - if (thd->killed == ABORT_QUERY) > + if (thd->killed == ABORT_QUERY || thd->is_fatal_error) > { > error= 0; > goto err; that's kind of weird. Why does it continue executing if the statement is killed? Perhaps it'd better be if (thd->killed || thd->is_fatal_error) { if (thd->killed == ABORT_QUERY) error= 0; goto err; Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 2f812e800c0: MDEV-22447: SIGSEGV in Item::val_uint on EXPLAIN
by Sergei Golubchik 15 Oct '21

15 Oct '21

Hi, Oleksandr! On Oct 15, Oleksandr Byelkin wrote: > revision-id: 2f812e800c0 (mariadb-10.2.40-57-g2f812e800c0) > parent(s): 696de6d06c0 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2021-09-16 14:12:48 +0200 > message: > > MDEV-22447: SIGSEGV in Item::val_uint on EXPLAIN > > take into account possible NULL > > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index ff584e936b7..d1b738e94a0 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -389,7 +389,7 @@ bool handle_select(THD *thd, LEX *lex, select_result *result, > ER_QUERY_EXCEEDED_ROWS_EXAMINED_LIMIT, > ER_THD(thd, ER_QUERY_EXCEEDED_ROWS_EXAMINED_LIMIT), > thd->accessed_rows_and_keys, > - thd->lex->limit_rows_examined->val_uint()); > + thd->lex->get_limit_rows_examined()); > thd->abort_on_warning= saved_abort_on_warning; > thd->reset_killed(); > } How comes, it gets into ER_QUERY_EXCEEDED_ROWS_EXAMINED_LIMIT if limit_rows_examined is NULL? Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] cd4cac2b95a: MDEV-17964: Assertion `status == 0' failed in add_role_user_mapping_action
by Sergei Golubchik 15 Oct '21

15 Oct '21

Hi, Vicențiu! The patch is ok, please push. But given the time it took us to understand the issue, I'm afraid that simply stating that "HASH implementation shuffles elements around" is not enough. Better to explain how elements are shuffled around. For example: in this case the hash has 131 element, DROP ROLE removes the element [119]. Its [119]->next was element [129], so [129] is moved to [119]. Now we need to compact the hash, removing the last element [130]. It gets one bit off its hash value and becomes element [2]. The existing element [2] is moved to [129], and old [130] is moved to [2]. We cannot simply move [130] to [129] and make [2]->next=130, it won't work if [2] is itself in the collision list and doesn't belong in [2]. On Oct 15, Vicențiu Ciorbaru wrote: > revision-id: cd4cac2b95a (mariadb-10.2.40-91-gcd4cac2b95a) > parent(s): 2bb8d7c2f36 > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2021-10-13 13:28:50 +0300 > message: > > MDEV-17964: Assertion `status == 0' failed in add_role_user_mapping_action > > This happens upon CREATE USER and DROP ROLE. > > The underlying problem is that our HASH implementation shuffles > elements around when performing an update or delete. This means that > when doing a scan through the HASH table by index, in search of > elements to delete or update one must restart the scan to make sure > nothing is missed if at least one delete / update happened. > > The handle_grant_struct code assumed that it is safe to continue by > only reexamining the currently modified / deleted element index, but > that is not true. > > Missing to delete an element in the hash triggered the assertion in > the test case. DROP ROLE would not clear all necessary role->role or > role->user mappings. > > To fix the problem we ensure that the scan is restarted, only if an > element was deleted / updated, similar to how bubble-sort keeps > sorting until it finds no more elements to swap. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0