- developers - lists.mariadb.org

Re: [Maria-developers] d8e915a88fc: MDEV-26009 Server crash when calling twice procedure using FOR-loop
by Sergei Golubchik 20 Mar '22

20 Mar '22

Hi, Oleksandr, ok to push also, see below On Mar 20, Oleksandr Byelkin wrote: > revision-id: d8e915a88fc (mariadb-10.3.33-32-gd8e915a88fc) > parent(s): 6a2d88c1322 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2022-03-18 11:13:09 +0100 > message: > > MDEV-26009 Server crash when calling twice procedure using FOR-loop > > The problem was that instructions sp_instr_cursor_copy_struct and > sp_instr_copen uses the same lex, adding and removing "tail" of > prelocked tables and forgetting that tail of all tables is kept in > LEX::query_tables_last. If the LEX used only by one instruction > or the query do not have prelocked tables it is not important. > But to work correctly in all cases LEX::query_tables_last should > be reset to make new tables added in the correct list (after last > table in the LEX instead after last table of the prelocking "tail" > which was cut). > > diff --git a/sql/sp_head.cc b/sql/sp_head.cc > index 57ab31d9edf..96dc78dcf49 100644 > --- a/sql/sp_head.cc > +++ b/sql/sp_head.cc > @@ -3486,6 +3486,11 @@ sp_lex_keeper::reset_lex_and_exec_core(THD *thd, uint *nextp, > lex_query_tables_own_last= m_lex->query_tables_own_last; > prelocking_tables= *lex_query_tables_own_last; > *lex_query_tables_own_last= NULL; > + /* > + Here we cut "tail" of prelocked tables, so have to return last table > + to the original position (wuthout the tail > + */ > + m_lex->query_tables_last= m_lex->query_tables_own_last; 1. the comment looks truncated 2. I don't even think this line needs a comment, this code block removes the list of prelocked tables from the query_tables list. Looking at how query_tables_last and query_tables_own_last are documented: /* Pointer to next_global member of last element in the previous list. */ TABLE_LIST **query_tables_last; /* If non-0 then indicates that query requires prelocking and points to next_global member of last own element in query table list (i.e. last table which was not added to it as part of preparation to prelocking). 0 - indicates that this query does not need prelocking. */ TABLE_LIST **query_tables_own_last; it is pretty clear that after the "tail" is removed, one has to set query_tables_last to point to the end of the list. The fact that it wasn't done was clearly an omission. That is, existing code and existing comments document it pretty well, your comment looks redundant and even confusing to me. So, please, remove the comment and ok to push > m_lex->mark_as_requiring_prelocking(NULL); > } > thd->rollback_item_tree_changes(); Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] Google Summer of Code 2022
by Vicențiu Ciorbaru 20 Mar '22

20 Mar '22

Hi Sergey! I'm happy to see that you have experience in MariaDB code base already. The MDEV-18827 is definitely up for grabs for GSoC 2022. The project is mostly a part-time project (requiring a commitment of around 175 hours), however depending on your availability we can increase the scope of the project and bump it up to a full time project. My suggestion for this task is to start looking at code parsing FRM files. Search for the function TABLE_SHARE::init_from_binary_frm_image to get an idea how an .frm is structured. After that, think how you would like to implement the feature described in MDEV-18827. Feel free to submit a draft proposal and we can iterate on it. Not 100% sure how the GSoC interface works this year, but last time you were able to share with potential mentors a Google Doc with the possibility to comment. Have a look at the proposal guidelines https://mariadb.org/gsoc2022-instructions/ and start writing it. When the program application opens you can submit it (4th of April). In the meantime, feel free to ask any questions you might have here. I encourage you to keep all discussions on the mailing list as much as possible so others can chime in. Vicențiu On Sat, 19 Mar 2022 at 09:54, Сергей Ваниславский <serzhmn(a)gmail.com> wrote: > Hello Vicentiu! > My name is Vanislavsky Sergey. Your colleague Nikita Malyavin > recommended contacting you about GSoC.I would like to do your task > MDEV-18827. I am a 3rd year student at FEFU. Here is my last pull request: > https://github.com/MariaDB/server/pull/2016 > Thank you for your consideration. >

1 0

[Maria-developers] Relevance of MDEV-19556
by Vladisav Kakurin 17 Mar '22

17 Mar '22

Hi, Vicențiu! With my mentor Nikita Malyavin we chose the topic of my bachelor's graduation work, and I was really interested in the MDEV-19556 <https://jira.mariadb.org/browse/MDEV-19556> ticket. Could you say some words about this, maybe the ticket ain’t actual, or something about work that was done by one of the developers to this direction?

1 0

Re: [Maria-developers] 2467eb2d314: MDEV-27743 Remove Lex::charset
by Sergei Golubchik 16 Mar '22

16 Mar '22

Hi, Alexander, I had only a couple of questions/comments, see below: On Mar 11, Alexander Barkov wrote: > revision-id: 2467eb2d314 (mariadb-10.6.1-330-g2467eb2d314) > parent(s): 61b72ed3dde > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-10 10:27:55 +0400 > message: > > MDEV-27743 Remove Lex::charset > > This patch also fixes: > MDEV-27690 Crash on `CHARACTER SET csname COLLATE DEFAULT` in column definition how do you plan to fix it in 10.2-10.8 ? > > diff --git a/mysql-test/main/ctype_collate_column.result b/mysql-test/main/ctype_collate_column.result > new file mode 100644 > index 00000000000..b20be5d3a48 > --- /dev/null > +++ b/mysql-test/main/ctype_collate_column.result > @@ -0,0 +1,450 @@ > +# > +# Start of 10.9 tests > +# > +# > +# MDEV-27743 Remove Lex::charset 1. Jira doesn't explain what user-visible changes one can expect. If there are none, it's not clear why you needed this big test case 2. the test is totally unreadable. Could you do a normal test instead? Like, put `select` instead of `execute immediate` and convert the output to a .test file? > +# > +CREATE TABLE cs (cs VARCHAR(64) NOT NULL); > +INSERT INTO cs (cs) VALUES > +(''), > +('CHARACTER SET latin1'), > +('CHARACTER SET utf8mb4'); > +CREATE TABLE cl0 (cl0 VARCHAR(64) NOT NULL); > +INSERT INTO cl0 (cl0) VALUES > +(''), > +('BINARY'), > +('COLLATE DEFAULT'), > +('COLLATE latin1_bin'), > +('COLLATE latin1_swedish_ci'), > +('COLLATE utf8mb4_bin'), > +('COLLATE utf8mb4_general_ci'); > +CREATE TABLE cl1 (cl1 VARCHAR(64) NOT NULL); > +INSERT INTO cl1 (cl1) VALUES > +(''), > +('COLLATE DEFAULT'), > +('COLLATE latin1_bin'), > +('COLLATE latin1_swedish_ci'), > +('COLLATE utf8mb4_bin'), > +('COLLATE utf8mb4_general_ci'); ... > diff --git a/mysql-test/main/ctype_latin1.result b/mysql-test/main/ctype_latin1.result > index 0b16d1cf6f2..70577f2c22c 100644 > --- a/mysql-test/main/ctype_latin1.result > +++ b/mysql-test/main/ctype_latin1.result > @@ -8889,6 +8889,38 @@ a b > 111 111 > DROP TABLE t1; > # > +# MDEV-27690 Crash on `CHARACTER SET csname COLLATE DEFAULT` in column definition > +# > +CREATE TABLE t1 (a CHAR(10) CHARACTER SET latin1 COLLATE DEFAULT); > +SHOW CREATE TABLE t1; > +Table Create Table > +t1 CREATE TABLE `t1` ( > + `a` char(10) DEFAULT NULL > +) ENGINE=MyISAM DEFAULT CHARSET=latin1 > +DROP TABLE t1; > +SELECT CAST('a' AS CHAR(10) CHARACTER SET latin1 COLLATE DEFAULT); > +CAST('a' AS CHAR(10) CHARACTER SET latin1 COLLATE DEFAULT) > +a > +CREATE TABLE t1 AS > +SELECT CAST('a' AS CHAR(10) CHARACTER SET latin1 COLLATE DEFAULT) AS c1; > +SHOW CREATE TABLE t1; > +Table Create Table > +t1 CREATE TABLE `t1` ( > + `c1` varchar(10) DEFAULT NULL > +) ENGINE=MyISAM DEFAULT CHARSET=latin1 > +DROP TABLE t1; > +SELECT COLUMN_GET(COLUMN_CREATE(0, 'string'),0 AS CHAR CHARACTER SET latin1 COLLATE DEFAULT) AS c1; > +c1 > +string > +CREATE TABLE t1 AS > +SELECT COLUMN_GET(COLUMN_CREATE(0, 'string'),0 AS CHAR CHARACTER SET latin1 COLLATE DEFAULT) AS c1; > +SHOW CREATE TABLE t1; > +Table Create Table > +t1 CREATE TABLE `t1` ( > + `c1` longtext DEFAULT NULL > +) ENGINE=MyISAM DEFAULT CHARSET=latin1 > +DROP TABLE t1; 1. why is it in "10.2 tests" ? 2. shouldn't here be at least one test that COLLATE DEFAULT is not a no-op? Like CREATE TABLE (... COLLATE DEFAULT ...) COLLATE _non_default ? Or is it in your generated ctype_collate_column.test? > +# > # End of 10.2 tests > # > # > diff --git a/mysql-test/suite/roles/create_and_drop_role_invalid_user_table.test b/mysql-test/suite/roles/create_and_drop_role_invalid_user_table.test > index 9cf0d7b4aff..dac6eab21e9 100644 > --- a/mysql-test/suite/roles/create_and_drop_role_invalid_user_table.test > +++ b/mysql-test/suite/roles/create_and_drop_role_invalid_user_table.test > @@ -36,7 +36,7 @@ set default role test_role for root@localhost; > drop role test_role; > drop user test_user@localhost; > > -alter table user add column default_role char(80) binary default '' not null > +alter table user add column default_role char(80) default '' not null > COLLATE utf8_general_ci Heh, interesting that it worked before good catch > after is_role; > alter table user add max_statement_time decimal(12,6) default 0 not null > diff --git a/sql/structs.h b/sql/structs.h > index 9a5006e8b47..db065c49931 100644 > --- a/sql/structs.h > +++ b/sql/structs.h > @@ -599,11 +599,140 @@ class DDL_options: public DDL_options_st ... > +class Lex_collation: public Lex_collation_st > +{ > +public: > + Lex_collation(CHARSET_INFO *collation, Type type) > + { > + m_collation= collation; > + m_type= type; > + } > + static Lex_collation national(bool bin_mod) > + { > + if (bin_mod) > + return Lex_collation(&my_charset_utf8mb3_bin, TYPE_EXPLICIT); > + return Lex_collation(&my_charset_utf8mb3_general_ci, TYPE_IMPLICIT); utf8mb3? not utf8? > + } > +}; > + > + > struct Lex_length_and_dec_st > { > -private: > +protected: > uint32 m_length; > uint8 m_dec; > + uint8 m_collation_type:2; > bool m_has_explicit_length:1; > bool m_has_explicit_dec:1; > public: > diff --git a/sql/sql_lex.cc b/sql/sql_lex.cc > index ae6ae9a0cc0..6ca10267187 100644 > --- a/sql/sql_lex.cc > +++ b/sql/sql_lex.cc > @@ -11816,3 +11784,257 @@ bool SELECT_LEX_UNIT::explainable() const ... > +CHARSET_INFO * > +Lex_collation_st::resolved_to_character_set(CHARSET_INFO *def) const > +{ > + DBUG_ASSERT(def); > + if (m_type != TYPE_CONTEXTUALLY_TYPED) > + { > + if (!m_collation) > + return def; // Empty - not typed at all > + return m_collation; // Explicitly typed > + } > + > + // Contextually typed > + DBUG_ASSERT(m_collation); > + > + if (m_collation == &my_charset_bin) // CHAR(10) BINARY > + return find_bin_collation(def); > + > + if (m_collation == &my_charset_latin1) // CHAR(10) COLLATE DEFAULT > + return find_default_collation(def); Uhm. Could you create two dummy CHARSET_INFO variables for that instead? Like CHARSET_INFO binary_collaton, default_collation; no need to initialize them, but to have distinct values for binary/default and not reuse my_charset_bin and my_charset_latin1. > + > + /* > + Non-binary and non-default contextually typed collation. > + We don't have such yet - the parser cannot produce this. > + But will have soon, e.g. "uca1400_as_ci". > + */ > + DBUG_ASSERT(0); > + return NULL; > +} > + > + ... > diff --git a/sql/field.h b/sql/field.h > index 2ed02b37cfd..fe5ba435202 100644 > --- a/sql/field.h > +++ b/sql/field.h > @@ -5493,6 +5492,22 @@ class Column_definition: public Sql_alloc, > { return compression_method_ptr; } > > bool check_vcol_for_key(THD *thd) const; > + > + void set_lex_collation(const Lex_collation_st &lc) > + { > + charset= lc.collation(); > + if (lc.is_contextually_typed_collation()) > + flags|= BINCMP_FLAG; > + else > + flags&= ~BINCMP_FLAG; Isn't COLLATE DEFAULT also contextually typed? > + } > + Lex_collation lex_collation() const > + { > + return Lex_collation(charset, > + flags & BINCMP_FLAG ? > + Lex_collation_st::TYPE_CONTEXTUALLY_TYPED : > + Lex_collation_st::TYPE_IMPLICIT); > + } > }; > > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

2 2

Re: [Maria-developers] 75aa95ada6b: Tricky static asserts did not compile on some platforms. Commenting out.
by Sergei Golubchik 16 Mar '22

16 Mar '22

Hi, Alexander, On Mar 16, Alexander Barkov wrote: > revision-id: 75aa95ada6b (mariadb-10.6.1-338-g75aa95ada6b) > parent(s): e90062c20f1 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-03-09 13:07:35 +0400 > message: > > Tricky static asserts did not compile on some platforms. Commenting out. Details? What doesn't compile and where? I'd suggest to try to keep the assert in some form > diff --git a/sql/structs.h b/sql/structs.h > index abfafb635b1..23958490c7b 100644 > --- a/sql/structs.h > +++ b/sql/structs.h > @@ -602,13 +602,16 @@ class DDL_options: public DDL_options_st > > struct Lex_length_and_dec_st > { > + /* > + Does not compile on some platforms: > static constexpr uint collation_type_bits= 2; > static_assert(((1<<collation_type_bits)-1) >= > Lex_charset_collation_st::TYPE_LAST); > + */ > protected: > uint32 m_length; > uint8 m_dec; > - uint8 m_collation_type:collation_type_bits; > + uint8 m_collation_type:2; /*collation_type_bits;*/ > bool m_has_explicit_length:1; > bool m_has_explicit_dec:1; > public: Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] e90062c20f1: MDEV-27266 Improve UCA collation performance for utf8mb3 and utf8mb4
by Sergei Golubchik 16 Mar '22

16 Mar '22

Hi, Alexander, also ok On Mar 14, Alexander Barkov wrote: > revision-id: e90062c20f1 (mariadb-10.6.1-337-ge90062c20f1) > parent(s): 6a3201d3769 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-28 14:43:43 +0400 > message: > > MDEV-27266 Improve UCA collation performance for utf8mb3 and utf8mb4 > > Adding two levels of optimization: > > include/m_ctype.h | 53 ++++ > strings/ctype-uca-scanner_next.inl | 39 +++ > strings/ctype-uca.c | 548 ++++++++++++++++++++++++++++++++++++- > strings/ctype-uca.ic | 30 ++ I thought all *.ic files were renamed to *.inl ? > unittest/strings/strings-t.c | 2 +- > 5 files changed, 660 insertions(+), 12 deletions(-) Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] 6a3201d3769: MDEV-27265 Improve contraction performance in UCA collations
by Sergei Golubchik 16 Mar '22

16 Mar '22

Hi, Alexander, that ok, up to you. I'm not looking into the strings/ctype*c code. On Mar 14, Alexander Barkov wrote: > revision-id: 6a3201d3769 (mariadb-10.6.1-336-g6a3201d3769) > parent(s): 49ecf935415 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-28 14:05:08 +0400 > message: > > MDEV-27265 Improve contraction performance in UCA collations > > Adding a hash table for contractions. > > The old code iterated through all items in MY_CONTRACTIONS, > and was much slower, especially for those contractions > in the end of the list. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] c67789f63c8: MDEV-27009 Add UCA-14.0.0 collations - adding version aware implicit weight handling
by Sergei Golubchik 14 Mar '22

14 Mar '22

Hi, Alexander, this is ok too, thanks On Mar 14, Alexander Barkov wrote: > revision-id: c67789f63c8 (mariadb-10.6.1-334-gc67789f63c8) > parent(s): c1010fdfac2 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-28 10:31:31 +0400 > message: > > MDEV-27009 Add UCA-14.0.0 collations - adding version aware implicit weight handling > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

Re: [Maria-developers] c1010fdfac2: MDEV-27009 Add UCA-14.0.0 collations - dump logical positions and contractions
by Sergei Golubchik 14 Mar '22

14 Mar '22

Hi, Alexander, this is ok too On Mar 14, Alexander Barkov wrote: > revision-id: c1010fdfac2 (mariadb-10.6.1-333-gc1010fdfac2) > parent(s): ab62059bbd4 > author: Alexander Barkov > committer: Alexander Barkov > timestamp: 2022-02-28 10:31:31 +0400 > message: > > MDEV-27009 Add UCA-14.0.0 collations - dump logical positions and contractions > Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

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