May 2020 - developers - lists.mariadb.org

Re: [Maria-developers] b22a28c2295: fixup! 3fe5cd5e1785e3e8de7add9977a1c2ddd403538b
by Sergei Golubchik 22 May '20

22 May '20

Hi, Michael! On May 20, Michael Widenius wrote: > revision-id: b22a28c2295 (mariadb-10.5.2-256-gb22a28c2295) > parent(s): acbe14b122c > author: Michael Widenius <monty(a)mariadb.com> > committer: Michael Widenius <monty(a)mariadb.com> > timestamp: 2020-05-19 17:52:18 +0300 > message: > > fixup! 3fe5cd5e1785e3e8de7add9977a1c2ddd403538b > > MDEV-22607 Assertion `ha_info->ht() != binlog_hton' failed in > MYSQL_BIN_LOG::unlog_xa_prepare > > diff --git a/sql/log.cc b/sql/log.cc > index 7e9e231358a..792c6bb1a99 100644 > --- a/sql/log.cc > +++ b/sql/log.cc > @@ -10128,11 +10128,6 @@ int TC_LOG_BINLOG::unlog_xa_prepare(THD *thd, bool all) > if (rw_count > 0) > { > /* an empty XA-prepare event group is logged */ > -#ifndef DBUG_OFF > - for (ha_info= thd->transaction->all.ha_list; rw_count > 1 && ha_info; > - ha_info= ha_info->next()) > - DBUG_ASSERT(ha_info->ht() != binlog_hton); > -#endif > rc= write_empty_xa_prepare(thd, cache_mngr); // normally gains need_unlog > trans_register_ha(thd, true, binlog_hton, 0); // do it for future commmit > } What does this assertion mean and what does it mean that it no longer holds? Regards, Sergei

2 1

Re: [Maria-developers] 20d54b09830: Update galera to work with independent sub transactions
by Sergei Golubchik 22 May '20

22 May '20

Hi, Michael! I see, you basically disable wsrep for these out-of-band transactions. I'm sure it works fine now, with Aria. But will it work with InnoDB? On May 20, Michael Widenius wrote: > revision-id: 20d54b09830 (mariadb-10.5.2-257-g20d54b09830) > parent(s): b22a28c2295 > author: Michael Widenius <monty(a)mariadb.com> > committer: Michael Widenius <monty(a)mariadb.com> > timestamp: 2020-05-19 17:55:00 +0300 > message: > > Update galera to work with independent sub transactions > > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index 51d7380f622..4c87cbeee59 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -5806,6 +5806,8 @@ start_new_trans::start_new_trans(THD *thd) > server_status= thd->server_status; > m_transaction_psi= thd->m_transaction_psi; > thd->m_transaction_psi= 0; > + wsrep_on= thd->variables.wsrep_on; > + thd->variables.wsrep_on= 0; > thd->server_status&= ~(SERVER_STATUS_IN_TRANS | > SERVER_STATUS_IN_TRANS_READONLY); > thd->server_status|= SERVER_STATUS_AUTOCOMMIT; Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 1

Re: [Maria-developers] c5238d7b3b7: MDEV-22545: my_vsnprintf behaves not as in C standard
by Sergei Golubchik 20 May '20

20 May '20

Hi, Oleksandr! On May 20, Oleksandr Byelkin wrote: > revision-id: c5238d7b3b7 (mariadb-10.5.3-200-gc5238d7b3b7) > parent(s): 8f9c53586bf > author: Oleksandr Byelkin <sanja(a)mariadb.com> > committer: Oleksandr Byelkin <sanja(a)mariadb.com> > timestamp: 2020-05-20 08:35:12 +0200 > message: > > MDEV-22545: my_vsnprintf behaves not as in C standard > > Added parameter %T for string which should be visibly truncated. > > diff --git a/include/mysql/service_my_snprintf.h b/include/mysql/service_my_snprintf.h > index bd1f069c527..94a9e07dcbb 100644 > --- a/include/mysql/service_my_snprintf.h > +++ b/include/mysql/service_my_snprintf.h > @@ -69,6 +70,9 @@ > Format 'M': takes one integer, prints this integer, space, double quote > error message, double quote. In other words > printf("%M", n) === printf("%d \"%s\"", n, strerror(n)) > + > + Format 'T': takes string and print it like s but if the strints shoud be should > + truncated puts "..." at the end. > */ > > #ifdef __cplusplus > diff --git a/mysql-test/main/frm-debug.result b/mysql-test/main/frm-debug.result > index caf344e241d..332d7e00a8f 100644 > --- a/mysql-test/main/frm-debug.result > +++ b/mysql-test/main/frm-debug.result > @@ -13,8 +13,8 @@ CREATE TABLE t1 (c01 INT, c02 CHAR(20), c03 TEXT, c04 DOUBLE); > Warnings: > Note 1105 build_frm_image: Field data type info length: 14 > Note 1105 DBUG: [0] name='c01' type_info='' > -Note 1105 DBUG: [1] name='c02' type_info='xc...' > -Note 1105 DBUG: [2] name='c03' type_info='xb...' > +Note 1105 DBUG: [1] name='c02' type_info='xchar' > +Note 1105 DBUG: [2] name='c03' type_info='xblob' good > Note 1105 DBUG: [3] name='c04' type_info='' > SET SESSION debug_dbug="-d,frm_data_type_info_emulate"; > SET SESSION debug_dbug="-d,frm_data_type_info"; > diff --git a/mysql-test/main/xml.result b/mysql-test/main/xml.result > index efaca961b4a..84dbd68438f 100644 > --- a/mysql-test/main/xml.result > +++ b/mysql-test/main/xml.result > @@ -1007,7 +1007,7 @@ Warning 1292 Truncated incorrect INTEGER value: 'string ' > Warning 1292 Truncated incorrect INTEGER value: 'string ' > DROP PROCEDURE spxml; > select UpdateXML('<a>a</a>',repeat('a b ',1000),''); > -ERROR HY000: XPATH syntax error: 'b a b a b a b a b a b a b a b...' > +ERROR HY000: XPATH syntax error: 'b a b a b a b a b a b a b a b a ' this doesn't look right, the string is truncated, isn't it? > select ExtractValue('<a>a</a>', '/a[@x=@y0123456789_0123456789_0123456789_0123456789]'); > ERROR HY000: XPATH error: comparison of two nodesets is not supported: '=@y0123456789_0123456789_0123...' > select ExtractValue('<a>a</a>', '/a[@x=$y0123456789_0123456789_0123456789_0123456789]'); > @@ -1110,9 +1110,9 @@ NULL > # Bug#57279 updatexml dies with: Assertion failed: str_arg[length] == 0 > # > SELECT UPDATEXML(NULL, (LPAD(0.1111E-15, '2011', 1)), 1); > -ERROR 22007: Illegal double '111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111...' value found during parsing > +ERROR 22007: Illegal double '111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111' value found during parsing same here, lpad appends 2011 characters, so this "double" is clearly truncated. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] b97e45651d1: MDEV-16937 Strict SQL with system versioned tables causes issues
by Sergei Golubchik 19 May '20

19 May '20

Hi, Aleksey! First - is commit b97e45651d1 the one I was supposed to review? On May 17, Aleksey Midenkov wrote: > revision-id: b97e45651d1 (mariadb-10.4.7-33-gb97e45651d1) > parent(s): 7587975bf06 > author: Aleksey Midenkov <midenok(a)gmail.com> > committer: Aleksey Midenkov <midenok(a)gmail.com> > timestamp: 2019-08-19 11:58:07 +0300 > message: > > MDEV-16937 Strict SQL with system versioned tables causes issues > > Vers SQL: respect system fields in NO_ZERO_DATE mode. > > This is the subject for refactoring in tempesta-tech/mariadb#379 > > diff --git a/mysql-test/suite/versioning/engines.combinations b/mysql-test/suite/versioning/engines.combinations > index 26b5bab23f1..57e2af6cd06 100644 > --- a/mysql-test/suite/versioning/engines.combinations > +++ b/mysql-test/suite/versioning/engines.combinations > @@ -7,5 +7,10 @@ default-storage-engine=innodb > [myisam] > default-storage-engine=myisam > > +[traditional] > +default-storage-engine=myisam > +sql-mode=traditional I'm not sure about it. It's, of course, safe to run all tests with every possible settings, but it really blows up testing times. May be it'd make sense to have a more targeted test here? > + > [heap] > default-storage-engine=memory > + > diff --git a/mysql-test/suite/versioning/r/select.result b/mysql-test/suite/versioning/r/select.result > index 3569268ce1d..68df246af6b 100644 > --- a/mysql-test/suite/versioning/r/select.result > +++ b/mysql-test/suite/versioning/r/select.result > @@ -45,7 +45,7 @@ ASOF_x y > 7 107 > 8 108 > 9 109 > -select x as FROMTO_x, y from t1 for system_time from timestamp '0-0-0 0:0:0' to timestamp @t1; > +select x as FROMTO_x, y from t1 for system_time from timestamp '1970-01-01 00:00:00' to timestamp @t1; Does this test use a fixed time zone? If not, is 1970-01-01 00:00:00 a valid timestamp in all time zones? If unsure, better use 1971, that will definitely be fine everywhere. > FROMTO_x y > 0 100 > 1 101 > diff --git a/sql/field.cc b/sql/field.cc > index 969c32a5180..f5580239a9f 100644 > --- a/sql/field.cc > +++ b/sql/field.cc > @@ -11139,6 +11139,13 @@ bool Field::save_in_field_default_value(bool view_error_processing) > { > THD *thd= table->in_use; > > + /* > + TODO: refactor setting the system fields via default_value mechanism. > + This condition will go away as well as other conditions with VERS_SYSTEM_FIELD. > + */ MDEV? There's a pull request, but it is marked as obsolete > + if (flags & VERS_SYSTEM_FIELD) > + return false; > + > if (unlikely(flags & NO_DEFAULT_VALUE_FLAG && > real_type() != MYSQL_TYPE_ENUM)) > { > diff --git a/sql/unireg.cc b/sql/unireg.cc > index d019b5f8a75..484ad0334e4 100644 > --- a/sql/unireg.cc > +++ b/sql/unireg.cc > @@ -1060,7 +1060,8 @@ static bool make_empty_rec(THD *thd, uchar *buff, uint table_options, > !f_bit_as_char(field->pack_flag)) > null_count+= field->length & 7; > > - error= make_empty_rec_store_default(thd, regfield, field->default_value); > + if (!(field->flags & VERS_SYSTEM_FIELD)) > + error= make_empty_rec_store_default(thd, regfield, field->default_value); will the field be initialized at all? It should have something, even bzero will do, but we shouldn't dump uninited memory to frm. > delete regfield; // Avoid memory leaks > if (error) > goto err; > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 3

[Maria-developers] Progress report - Week 2
by Mohammed Hammaad Mateen 18 May '20

18 May '20

Greetings, Hope you are safe and doing great, This post describes the things I've done in my second week [ 11-17 May ] of Community Bonding Period under the mentor-ship of Sergei Golubchik and Oleksandr Byelkin for GSoC-20. Tasks done this week were mostly the continuation of the leftover tasks from the previous week and some related study. Things I've done include: 1:* I was caught up in analysing how was DELETE .... RETURNING implemented, which led me to read from:* • *sp_head.cc* : this made me understand that sp actually meant stored procedures but there is another called PS which I'm yet to figure out. • *sql_parse.cc* : from here I understood that delete return as actually { Analyse->Delete->Return } and all the logic for returning is executed if(lex->has_returning()). 2: Though I've raised the pull request, *MDEV-14558* is not yet completely tested as it does not include tests for *mysql \s*, moreover, I'm facing problems to escape the backslash inorder to write a test-case for *mysql \s* . Regards, Mohammed Hammaad Mateen

1 0

Re: [Maria-developers] 82b6a5cb85f: MDEV-22556: Incorrect result for window function when using encrypt-tmp-files=ON
by Sergei Golubchik 17 May '20

17 May '20

Hi, Varun! Ok to push. One comment below On May 17, Varun Gupta wrote: > revision-id: 82b6a5cb85f (mariadb-10.4.11-192-g82b6a5cb85f) > parent(s): 3bfe305c5cd > author: Varun Gupta <varun.gupta(a)mariadb.com> > committer: Varun Gupta <varun.gupta(a)mariadb.com> > timestamp: 2020-05-15 02:37:16 +0530 > message: > > MDEV-22556: Incorrect result for window function when using encrypt-tmp-files=ON > > diff --git a/mysql-test/suite/encryption/t/tempfiles_encrypted.opt b/mysql-test/suite/encryption/t/tempfiles_encrypted.opt > new file mode 100644 > index 00000000000..f515f7b8689 > --- /dev/null > +++ b/mysql-test/suite/encryption/t/tempfiles_encrypted.opt > @@ -0,0 +1,5 @@ > +--encrypt-tmp_files=ON > +--loose-file-key-management-encryption-algorithm=aes_cbc > +--file-key-management=FORCE > +--loose-file-key-management-filename=$MTR_SUITE_DIR/t/filekeys-data.enc > +--loose-file-key-management-filekey=FILE:$MTR_SUITE_DIR/t/filekeys-data.key this is very redundant, you include have_file_key_management_plugin.inc and it already sets all options for the file_key_management plugin to work. so you only need --encrypt-tmp_files=ON here. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

[Maria-developers] Progress Report - Week 1-2
by Anton Mikhaylenko 17 May '20

17 May '20

Good day, everyone. In this post, I want to describe the things I've done in the 1-2 weeks of GSoC-20. For begin, I messaged with my mentor Vladislav Vaintroub and I got some tips on where to start. The first step was to run the server and tests for MariaDB on Linux and Windows. At this stage, a little bug was found, which was documented by my mentor https://jira.mariadb.org/browse/MDEV-22479. The next step was to look at the theoretical part of my work. Specifically, what algorithm to use for dynamic concurrency. This is the algorithm "hill-climbing", which is used in .NET ThreadPool https://www.researchgate.net/publication/228977836_Optimizing_concurrency_l… . In the last step, I started to get into the work of the current ThreadPool in MariaDB. At the moment this step is not completed yet. What needs to be done next: Fully understand the theoretic part and how the current thread pool works. Regards, Anton MIkhailenko

1 0

Re: [Maria-developers] Review for MDEV-19751.
by Aleksey Midenkov 14 May '20

14 May '20

Hi, Alexey! Actually the bug is applicable only to primary key and only when default field list is set (i.e. empty KEY() clause). So updated the patch accordingly. Please peek again. On Wed, May 13, 2020 at 2:40 PM Alexey Botchkov <holyfoot(a)mariadb.com> wrote: > > Hello, Aleksey! > > > commit 5ef168e00f7b8c821463e46535a4beccb47ec8ea > + if (key_info->flags & HA_INVISIBLE_KEY) > + continue; > > I'd add || !(key_info->flags & HA_NOSAME). > Can the non-unique index participate in the KEY partitioning? > > + for (uint kp= 0; kp < key_info->user_defined_key_parts; ++kp) > + { > + const KEY_PART_INFO &key_part= key_info->key_part[kp]; > + for (Field **part_field= tab_part_info->part_field_array; > + *part_field; ++part_field) > + { > + if (*part_field == key_part.field) > + { > + *partition_changed= TRUE; > + goto search_finished; > + } > + } // for (part_field) > + } // for (key_part) > > So you check if the key has any of the partitioning fields in it. > In this case we are going to disallow INPLACE with no reason if the > unrelated key is removed just containing the primary key column. > I'd say we should check for the exact match, when the key has > all the part_field_array in that exact order. Disagree? > > And for the test - please add the case for a table with no PRIMARY KEY, bug with the UNIQUE instead. > > Best regards! > HF > -- All the best, Aleksey Midenkov @midenok

1 0

[Maria-developers] Progress Report - Week 1
by Mohammed Hammaad Mateen 12 May '20

12 May '20

Greetings, Hope you are safe and doing great, This post describes the things I've done in my first week [ 4-10 May ] of Community Bonding Period under the mentor-ship of Sergei Golubchik and Oleksandr Byelkin for GSoC-20 and I must acknowledge that it was really an interactive experience and at the same time informative as well. Things I've done include: 1: *Raising my first ever pull request for MariaDB under MDEV-14558 *: Learnt about *strnxmov*, a function of C++ which I had never used earlier. I also came across the procedure of testing my implemented code. Wrote some test cases for the same and generated their corresponding results. 2:* Understand the working of the functions under multi_delete*: Ran it in the debugger and tried to familiarize myself with the internals of how Multiple Table Delete actually works. Things to-do: 1: Though I've raised the pull request, MDEV-14558 is not completed tested as it does not include tests for *mysql \s*, moreover, test cases have to be refactored. 2: Learn more about the working of *multi_delete* so as to develop a parser for Multiple Table Delete Returning. 3: Write some test cases for Multiple Table Delete Returning before hand. Regards, Mohammed Hammaad Mateen

2 1

[Maria-developers] Review for: MDEV-17399 Add support for JSON_TABLE, part #3
by Sergey Petrunia 10 May '20

10 May '20

Hi Alexey, Please find the next batch of input below. (I haven't finished the review but I'm sending it now so you can start addressing it) > commit 68ca18518337443090bdeddf6d612129b6843c21 > Author: Alexey Botchkov <holyfoot(a)askmonty.org> > Date: Fri Apr 17 14:42:40 2020 +0400 > > MDEV-17399 Add support for JSON_TABLE. > > Syntax for JSON_TABLE added. > The ha_json_table handler added. Executing the JSON_TABLE we > create the temporary table of the ha_json_table, add dependencies > of other tables and sometimes conditions to WHERE. > ... > +public: > + ha_json_table(TABLE_SHARE *share_arg, Table_function_json_table *jt): > + handler(&table_function_hton.m_hton, share_arg), m_jt(jt) > + { > + mark_trx_read_write_done= 1; This definitely needs a comment. > + ~ha_json_table() {} > + handler *clone(const char *name, MEM_ROOT *mem_root) { return NULL; } > + const char *index_type(uint inx) { return "HASH"; } Why is ha_json_table still trying to pretend it supports indexes? Is this a left-over from the old way of interfacing with the optimizer that can now be removed? > +int Table_function_json_table::setup(THD *thd, TABLE_LIST *sql_table, > + COND **cond) > +{ > + if (m_json->fix_fields(thd, &m_json)) > + return TRUE; > + > + m_dep_tables= m_json->used_tables(); Why does this function have a 'cond' argument? Please remove it if it's not necessary. == Duplicate column names are allowed == select * from JSON_TABLE('{"color": "black", "price": 1000}', "$" COLUMNS (rowSeq FOR ORDINALITY, color VARCHAR(100) PATH '$.color', color VARCHAR(100) PATH '$.price') ) as T; +--------+-------+-------+ | rowSeq | color | color | +--------+-------+-------+ | 0 | black | 1000 | +--------+-------+-------+ Is it really okay that duplicate column names are allowed? == RIGHT JOIN is allowed == create table t1 (item_name varchar(32), item_props varchar(1024)); insert into t1 values ('Laptop', '{"color": "black", "price": 1000}'); insert into t1 values ('Jeans', '{"color": "blue", "price": 50}'); This query should not be allowed, because JSON_TABLE has a dependency on an inner side of an outer join: select * from t1 right join json_table(t1.item_props, '$' columns(color varchar(100) path '$.color', f2 for ordinality) ) as T on 1; === NATURAL JOIN crashes == create table t10 (color varchar(100), f2 int); select * from t10 natural join json_table(t1.item_props, '$' columns(color varchar(100) path '$.color', f2 for ordinality) ) as JT ; Thread 31 "mysqld" received signal SIGSEGV, Segmentation fault. 0x0000555555d8ac12 in Select_limit_counters::get_select_limit (this=0xa5a5a5a5a5a5ad2d) at /home/psergey/dev-git/10.5-json/sql/sql_limit.h:67 (gdb) wher #0 0x0000555555d8ac12 in Select_limit_counters::get_select_limit (this=0xa5a5a5a5a5a5ad2d) at /home/psergey/dev-git/10.5-json/sql/sql_limit.h:67 #1 0x0000555555e2a4a0 in JOIN::optimize_inner (this=0x7fffac018520) at /home/psergey/dev-git/10.5-json/sql/sql_select.cc:1805 #2 0x0000555555e29b12 in JOIN::optimize (this=0x7fffac018520) at /home/psergey/dev-git/10.5-json/sql/sql_select.cc:1612 BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 1