March 2022 - developers - lists.mariadb.org

Re: [Maria-developers] ab62059bbd4: MDEV-27009 Add UCA-14.0.0 collations - Adding implicit weight handling for Unicode-14.0.0
by Sergei Golubchik 14 Mar '22

14 Mar '22

Hi, Alexander, I believe it's ok too, but see a couple of questions below On Mar 14, Alexander Barkov wrote: > revision-id: ab62059bbd4 (mariadb-10.6.1-332-gab62059bbd4) > parent(s): 5fe33342399 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-28 10:31:06 +0400 > message: > > MDEV-27009 Add UCA-14.0.0 collations - Adding implicit weight handling for Unicode-14.0.0 > > diff --git a/strings/ctype-uca.c b/strings/ctype-uca.c > index ad0b46ea296..eb6bc2eb9e6 100644 > --- a/strings/ctype-uca.c > +++ b/strings/ctype-uca.c > @@ -31694,7 +31694,7 @@ static inline void > my_uca_implicit_weight_put(uint16 *to, my_wc_t code, uint level) > { > MY_UCA_IMPLICIT_WEIGHT weight; > - weight= my_uca_520_implicit_weight_on_level(code, level); > + weight= my_uca_implicit_weight_on_level(520, code, level); will the version always be a constant in every invocation of my_uca_implicit_weight_put() ? > to[0]= weight.weight[0]; > to[1]= weight.weight[1]; > to[2]= 0; > diff --git a/strings/ctype-uca.h b/strings/ctype-uca.h > index 01f655b06cb..d439b8c578c 100644 > --- a/strings/ctype-uca.h > +++ b/strings/ctype-uca.h > @@ -136,11 +149,11 @@ my_uca_implicit_weight_quaternary() > > > static inline MY_UCA_IMPLICIT_WEIGHT > -my_uca_520_implicit_weight_on_level(my_wc_t code, uint level) > +my_uca_implicit_weight_on_level(uint version, my_wc_t code, uint level) > { > switch (level) { > case 0: > - return my_uca_520_implicit_weight_primary(code); > + return my_uca_implicit_weight_primary(version, code); > case 1: > return my_uca_implicit_weight_secondary(); > case 2: do you mean that secondary/tertiary/etc weights do not depend on the version? Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 5fe33342399: MDEV-27009 Add UCA-14.0.0 collations - adding uca-dump into build targets
by Sergei Golubchik 14 Mar '22

14 Mar '22

Hi, Alexander, this is ok (not ok to push as is just yet, please wait until we agree on commits in the branch) On Mar 14, Alexander Barkov wrote: > revision-id: 5fe33342399 (mariadb-10.6.1-331-g5fe33342399) > parent(s): 2467eb2d314 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-10 11:53:47 +0400 > message: > > MDEV-27009 Add UCA-14.0.0 collations - adding uca-dump into build targets > > - Adding uca-dump into build targets > - Adding ctype-uca.h and moving implicit weight related routines there > - Reusing implicit weight routines in ctype-uca.c and uca-dump.c > - Adding handling of command line arguments to uca-dump > - Fixing some compile-time warnings in uca-dump.c > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 61b72ed3dde: MDEV-27712 Reduce the size of Lex_length_and_dec_st from 16 to 8
by Sergei Golubchik 11 Mar '22

11 Mar '22

Hi, Alexander, a question about error codes: On Mar 11, Alexander Barkov wrote: > commit 61b72ed3dde > Author: Alexander Barkov <bar(a)mariadb.com> > Date: Wed Feb 9 17:59:38 2022 +0400 > > diff --git a/mysql-test/main/type_blob.test b/mysql-test/main/type_blob.test > index c61ed124139..a5410244ed1 100644 > --- a/mysql-test/main/type_blob.test > +++ b/mysql-test/main/type_blob.test > @@ -517,7 +517,7 @@ CREATE TABLE b15776 (a char(2147483648)); > --error ER_TOO_BIG_FIELDLENGTH > CREATE TABLE b15776 (a char(4294967295)); > # Even BLOB won't hold > ---error ER_TOO_BIG_FIELDLENGTH > +--error ER_NOT_SUPPORTED_YET Why did you change the error? > CREATE TABLE b15776 (a char(4294967296)); > > > diff --git a/mysql-test/main/type_float.result b/mysql-test/main/type_float.result > index 5137a8229b6..9e216711ddd 100644 > --- a/mysql-test/main/type_float.result > +++ b/mysql-test/main/type_float.result > @@ -1162,3 +1162,36 @@ fdec 123.456.789,12345678900000000000000000000000000000 > # > # End of 10.4 tests > # > +# > +# Start of 10.9 tests > +# > +# > +# MDEV-27712 Reduce the size of Lex_length_and_dec_st from 16 to 8 > +# > +CREATE TABLE t1 (a DOUBLE(1000,1000)); > +ERROR 42000: This version of MariaDB doesn't yet support 'scale>255' > +CREATE TABLE t1 (a DOUBLE(1000,0)); > +ERROR 42000: Display width out of range for 'a' (max = 255) > +CREATE TABLE t1 (a DOUBLE(0,1000)); > +ERROR 42000: This version of MariaDB doesn't yet support 'scale>255' > +CREATE TABLE t1 (a DOUBLE(2147483647,2147483647)); > +ERROR 42000: This version of MariaDB doesn't yet support 'scale>255' > +CREATE TABLE t1 (a DOUBLE(2147483647,0)); > +ERROR 42000: Display width out of range for 'a' (max = 255) > +CREATE TABLE t1 (a DOUBLE(0,2147483647)); > +ERROR 42000: This version of MariaDB doesn't yet support 'scale>255' > +CREATE TABLE t1 (a DOUBLE(2147483648,2147483648)); > +ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '2147483648,2147483648))' at line 1 This isn't technically a *syntax* error Can you use a different error here? > +CREATE TABLE t1 (a DOUBLE(2147483648,0)); > +ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '2147483648,0))' at line 1 > +CREATE TABLE t1 (a DOUBLE(0,2147483648)); > +ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '2147483648))' at line 1 > +CREATE TABLE t1 (a DOUBLE(999999999999999999999999999999,999999999999999999999999999999)); > +ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '999999999999999999999999999999,999999999999999999999999999999))' at line 1 > +CREATE TABLE t1 (a DOUBLE(999999999999999999999999999999,0)); > +ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '999999999999999999999999999999,0))' at line 1 > +CREATE TABLE t1 (a DOUBLE(0,999999999999999999999999999999)); > +ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '999999999999999999999999999999))' at line 1 > +# > +# End of 10.9 tests > +# > diff --git a/sql/sql_yacc.yy b/sql/sql_yacc.yy > index 5bb03544762..fdc54f7df27 100644 > --- a/sql/sql_yacc.yy > +++ b/sql/sql_yacc.yy > @@ -5975,11 +5977,10 @@ field_type_numeric: > | FLOAT_SYM float_options last_field_options > { > $$.set(&type_handler_float, $2); > - if ($2.length() && !$2.dec()) > + if ($2.has_explicit_length() && !$2.has_explicit_dec()) > { > - int err; > - ulonglong tmp_length= my_strtoll10($2.length(), NULL, &err); > - if (unlikely(err || tmp_length > PRECISION_FOR_DOUBLE)) > + ulonglong tmp_length= $2.length(); you don't really need tmp_length here anymore > + if (unlikely(tmp_length > PRECISION_FOR_DOUBLE)) > my_yyabort_error((ER_WRONG_FIELD_SPEC, MYF(0), > Lex->last_field->field_name.str)); > if (tmp_length > PRECISION_FOR_FLOAT) Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 0402f6dcb67: MDEV-25477 Auto-create breaks replication when triggering event was not replicated
by Sergei Golubchik 07 Mar '22

07 Mar '22

Hi, Aleksey, This was quite good, thanks! Many cases covered, not just ROLLBACK, but also LIMIT 0 and impossible WHERE. See a couple of comments below. Nothing big. On Feb 12, Aleksey Midenkov wrote: > commit 0402f6dcb67 > Author: Aleksey Midenkov <midenok(a)gmail.com> > Date: Tue Feb 8 22:54:03 2022 +0300 > > diff --git a/sql/sql_delete.cc b/sql/sql_delete.cc > index 0403d6e73c3..06068290247 100644 > --- a/sql/sql_delete.cc > +++ b/sql/sql_delete.cc > @@ -507,6 +508,18 @@ bool mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds, > if (thd->lex->describe || thd->lex->analyze_stmt) > goto produce_explain_and_leave; > > + if (thd->log_current_statement) > + { > + thd->reset_unsafe_warnings(); > + if (thd->binlog_query(THD::STMT_QUERY_TYPE, > + thd->query(), thd->query_length(), > + transactional_table, FALSE, FALSE, 0) > 0) > + { > + my_error(ER_ERROR_ON_WRITE, MYF(0), "binary log", -1); > + DBUG_RETURN(1); > + } > + } perhaps, move this block into a function? It's repeated four times here. by the way, you don't seem to have a test for a zero-rows insert. That is INSERT ... SELECT with an impossible where or limit 0. In fact, you can have a zero-row insert with a normal insert INSERT t1 VALUES (1); if this (1) is a unique key violation. I believe your code handles this case, thought, just a test case is missing. > + > my_ok(thd, 0); > DBUG_RETURN(0); > } > @@ -932,8 +958,8 @@ bool mysql_delete(THD *thd, TABLE_LIST *table_list, COND *conds, > else > errcode= query_error_code(thd, killed_status == NOT_KILLED); > > - ScopedStatementReplication scoped_stmt_rpl( > - table->versioned(VERS_TRX_ID) ? thd : NULL); > + StatementBinlog stmt_binlog(thd, table->versioned(VERS_TRX_ID) || > + thd->binlog_need_stmt_format(transactional_table)); I know that's not part of this patch, but still. Just trying to understand. Why did it change to statement-based if VERS_TRX_ID? > /* > [binlog]: If 'handler::delete_all_rows()' was called and the > storage engine does not inject the rows itself, we replicate Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 3

Re: [Maria-developers] 880e92a48ba: MDEV-27760 event may non stop replicate in circular semisync setup
by Sergei Golubchik 07 Mar '22

07 Mar '22

Hi, Andrei, I don't see a point in caching the value in memory that is very cheap to calculate per event. I've pushed f8ec4dd38d0 to 10.4-serg three hours ago and Jenkins said it's fine. So I'd suggest we go with it, because we really have to close this blocker and release ES now. And MDEV-27837 will be fixed as a separate bug. queue_event checks global_system_variables.server_id in multiple places, moving only do_accept_own_server_id into Master_info will not make it any better or worse against MDEV-27837. > > As far as I can see, you can calculate it for every event just the same. > > The per event computation is extraneous and not consistent with the > nature of the flag that belongs to the group of events. > > Also notice (or remember) a "FR" > MDEV-27837 disallow `set @@session.server_id` within transaction > so until this bug is fixed it's not 'just the same'. > > I am recomming the patch, assuming that you'll be fine with the Gtid time > only flag computation. > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 880e92a48ba: MDEV-27760 event may non stop replicate in circular semisync setup
by Sergei Golubchik 06 Mar '22

06 Mar '22

Hi, Andrei, On Mar 01, Andrei Elkin wrote: > > On Feb 28, Andrei wrote: > >> revision-id: 880e92a48ba (mariadb-10.6.6-16-g880e92a48ba) > >> parent(s): 4030a9fb2eb > >> author: Andrei > >> committer: Andrei > >> timestamp: 2022-02-21 14:58:13 +0200 > >> message: > >> > >> MDEV-27760 event may non stop replicate in circular semisync setup > >> > >> diff --git a/sql/slave.cc b/sql/slave.cc > >> index c0eef02ca7a..a1f4f4f0081 100644 > >> --- a/sql/slave.cc > >> +++ b/sql/slave.cc > >> @@ -6186,13 +6186,13 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > >> bool is_rows_event= false; > >> /* > >> The flag has replicate_same_server_id semantics and is raised to accept > >> - a same-server-id event on the semisync slave, for both the gtid and legacy > >> - connection modes. > >> - Such events can appear as result of this server recovery so the event > >> - was created there and replicated elsewhere right before the crash. At recovery > >> - it could be evicted from the server's binlog. > >> - */ > >> - bool do_accept_own_server_id= false; > >> + a same-server-id event group by the gtid strict mode semisync slave. > >> + Own server-id events can appear as result of this server crash-recovery: > >> + the transaction was created on this server then being master, got replicated > >> + elsewhere right before the crash before commit; > >> + finally at recovery the transaction gets evicted from the server's binlog. > >> + */ > >> + static bool do_accept_own_server_id= false; > > > > No, sorry, it cannot be static. If you need to preserve it between > > events, you can keep it, for example, in Master_info. > > The var is set by Gtid events to serve as a marker of the whole current Gtid-headed > group of event. > Only next Gtid event may change the current value. > > Why can't it? Why it cannot be static? Because it's not a property of the server, it's a property of a specific replication stream. Technically one can have a multi-source and do_accept_own_server_id could have different values for different masters. > > So, the question now is, why do you need to preserve the value of > > do_accept_own_server_id between queue_event invocations? > > The flag as said above applies to the whole group of events, so it's > preserved at least through so many > queue_event() calls as many event in the group (I count Gtid itself in). As far as I can see, you can calculate it for every event just the same. > >> @@ -6281,6 +6281,8 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > >> dbug_rows_event_count = 0; > >> };); > >> #endif > >> + s_id= uint4korr(buf + SERVER_ID_OFFSET); > >> + > >> mysql_mutex_lock(&mi->data_lock); > >> > >> switch (buf[EVENT_TYPE_OFFSET]) { > >> @@ -6722,6 +6724,11 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > >> > >> ++mi->events_queued_since_last_gtid; > >> inc_pos= event_len; > >> + > >> + do_accept_own_server_id= > >> + (s_id == global_system_variables.server_id && rpl_semi_sync_slave_enabled > >> + && mi->using_gtid != Master_info::USE_GTID_NO && opt_gtid_strict_mode) ? > >> + true : false; Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

[Maria-developers] MDEV-27776 EXPLAIN is about to get new columns, EXPLAIN EXTENDED|PARTITIONS will be deprecated
by Oleg Smirnov 03 Mar '22

03 Mar '22

* EXPLAIN SELECT prints "partitions", "filtered" columns and produces the warning with rewritten query * EXPLAIN EXTENDED and EXPLAIN PARTITIONS produce the same output as EXPLAIN SELECT and two warnings, the second warning is about EXPLAIN EXTENDED| PARTITIONS being deprecated (same as in MySQL 5.7) -- Best regards, ------------------------- *Oleg Smirnov* Sr. Software Engineer MariaDB Server Team

1 0

Re: [Maria-developers] 5d8838a79d5: MDEV-24920: Merge "old" SQL variable to "old_mode" sql variable
by Sergei Golubchik 02 Mar '22

02 Mar '22

Hi, Rucha, On Mar 02, Rucha Deodhar wrote: > revision-id: 5d8838a79d5 (mariadb-10.6.1-352-g5d8838a79d5) > parent(s): f8b3c661231 > author: Rucha Deodhar > committer: Rucha Deodhar > timestamp: 2022-02-15 22:29:54 +0530 > message: > > MDEV-24920: Merge "old" SQL variable to "old_mode" sql variable > > Analysis: There are 2 server variables- "old_mode" and "old". "old" is no > longer needed as "old_mode" has replaced it (however still used in some places > in the code). "old_mode" and "old" has same purpose- emulate behavior from > previous MariaDB versions. So they can be merged to avoid confusion. > Fix: Deprecate "old" variable and create another mode for @@old_mode to mimic > behavior of previous "old" variable. Create specific modes for specifix task > that --old sql variable was doing earlier and use the new modes instead. > > diff --git a/mysql-test/main/mysqld--help.result b/mysql-test/main/mysqld--help.result > index 7cbfa52b846..261dbe2ffe0 100644 > --- a/mysql-test/main/mysqld--help.result > +++ b/mysql-test/main/mysqld--help.result > @@ -683,7 +683,8 @@ The following specify which files/extra groups are read (specified before remain > --old-mode=name Used to emulate old behavior from earlier MariaDB or > MySQL versions. Any combination of: > NO_DUP_KEY_WARNINGS_WITH_IGNORE, NO_PROGRESS_INFO, > - ZERO_DATE_TIME_CAST, UTF8_IS_UTF8MB3 > + ZERO_DATE_TIME_CAST, UTF8_IS_UTF8MB3, > + INDEX_HINT_MASK_JOIN, CHECKSUM_SLOW_NULLS I'm sorry, I still cannot understand what these new modes do :( I know that it was my idea to use "CHECKSUM_SLOW_NULLS", but now I'm, like, "what does it mean?". Let's discuss it on slack INDEX_HINT_MASK_JOIN - this seems to be easier, what about INGORE_INDEX_ONLY_FOR_JOIN ? That's a bit long, but shorter than NO_DUP_KEY_WARNINGS_WITH_IGNORE. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 880e92a48ba: MDEV-27760 event may non stop replicate in circular semisync setup
by Sergei Golubchik 01 Mar '22

01 Mar '22

Hi, Andrei, On Feb 28, Andrei wrote: > revision-id: 880e92a48ba (mariadb-10.6.6-16-g880e92a48ba) > parent(s): 4030a9fb2eb > author: Andrei > committer: Andrei > timestamp: 2022-02-21 14:58:13 +0200 > message: > > MDEV-27760 event may non stop replicate in circular semisync setup > > diff --git a/sql/slave.cc b/sql/slave.cc > index c0eef02ca7a..a1f4f4f0081 100644 > --- a/sql/slave.cc > +++ b/sql/slave.cc > @@ -6186,13 +6186,13 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > bool is_rows_event= false; > /* > The flag has replicate_same_server_id semantics and is raised to accept > - a same-server-id event on the semisync slave, for both the gtid and legacy > - connection modes. > - Such events can appear as result of this server recovery so the event > - was created there and replicated elsewhere right before the crash. At recovery > - it could be evicted from the server's binlog. > - */ > - bool do_accept_own_server_id= false; > + a same-server-id event group by the gtid strict mode semisync slave. > + Own server-id events can appear as result of this server crash-recovery: > + the transaction was created on this server then being master, got replicated > + elsewhere right before the crash before commit; > + finally at recovery the transaction gets evicted from the server's binlog. > + */ > + static bool do_accept_own_server_id= false; No, sorry, it cannot be static. If you need to preserve it between events, you can keep it, for example, in Master_info. yes, I remember, that's where it was and I asked why it's in Master_info. You could've answered, that you need to preserve the value between queue_event invocations - I didn't realize that at the time. So, the question now is, why do you need to preserve the value of do_accept_own_server_id between queue_event invocations? > /* > FD_q must have been prepared for the first R_a event > inside get_master_version_and_clock() > @@ -6281,6 +6281,8 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > dbug_rows_event_count = 0; > };); > #endif > + s_id= uint4korr(buf + SERVER_ID_OFFSET); > + > mysql_mutex_lock(&mi->data_lock); > > switch (buf[EVENT_TYPE_OFFSET]) { > @@ -6722,6 +6724,11 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > > ++mi->events_queued_since_last_gtid; > inc_pos= event_len; > + > + do_accept_own_server_id= > + (s_id == global_system_variables.server_id && rpl_semi_sync_slave_enabled > + && mi->using_gtid != Master_info::USE_GTID_NO && opt_gtid_strict_mode) ? > + true : false; this is a ridiculous pattern bool var = (bool expr) ? true : false; don't do that. > } > break; > /* > @@ -6909,7 +6916,6 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > */ > > mysql_mutex_lock(log_lock); > - s_id= uint4korr(buf + SERVER_ID_OFFSET); > /* > Write the event to the relay log, unless we reconnected in the middle > of an event group and now need to skip the initial part of the group that > @@ -6955,7 +6961,7 @@ static int queue_event(Master_info* mi, const uchar *buf, ulong event_len) > else > if ((s_id == global_system_variables.server_id && > !(mi->rli.replicate_same_server_id || > - (do_accept_own_server_id= rpl_semi_sync_slave_enabled))) || > + do_accept_own_server_id)) || > event_that_should_be_ignored(buf) || > /* > the following conjunction deals with IGNORE_SERVER_IDS, if set > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0