- developers - lists.mariadb.org

[Maria-developers] Queries on ticket MDEV-7502(GSOC)
by Vishwanath Bharadwaj 22 Mar '17

22 Mar '17

Hi, Vishwanath! Hello MR. Sergei, I am Vishwanath Bharadwaj and I've contacted you earlier regarding the project. With the help of the code Kristian provided in the comment section of the ticket I was able to review the code of the project proceedings till date. I was very much impressed by the way it has been implemented. I don't have any major queries (just some minor issues on the implementation of the semaphores). I've also familiarized myself with some code of both statement based binary logging and row- based logging. I would also like to get into the details of what the provisioning mode permissions are? And the method of using the primary key to identify the remaining chunk is not quite effective because weare limiting the options only to tables with primary keys. This is quite a unique and interesting project and I'm looking forward to working and discussing with you on the same. Thank you:)

2 1

[Maria-developers] MDEV-10598 - bb-10.2-compatibility
by jerome brauge 22 Mar '17

22 Mar '17

Alexander, As requested, this is my last patch for MDEV-10598. Of course, I share this code under MCA. Best regards, Jérôme. > -----Message d'origine----- > De : Alexander Barkov [mailto:bar@mariadb.org] > Envoyé : mercredi 22 mars 2017 12:00 > À : jerome brauge > Objet : Re: MDEV-10598 - bb-10.2-compatibility > > Hello Jerome, > > > On 03/22/2017 01:37 PM, jerome brauge wrote: > > Hello Alexander, > > All works fine, thank you very much. > > Thanks for confirming! > > Can I ask you for some bureaucracy? > > Can you please send your last patch for "MDEV-10598 - bb-10.2- > compatibility" to maria-developers and specify that you share it under BSD > license? > > This is needed to officially accept your code into our trees. > > Thanks! > > > > Now, we are blocked by MDEV-12137 (delete or update statement with > the same source and target). > > When do you think you can work on it? > > Sorry, I don't have expertise in this part of the code. > > Somebody else will be working on it. > But I'm afraid this is not something of high priority at the moment. > > > > > > Regards, > > Jérôme. > > > >> -----Message d'origine----- > >> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : jeudi 16 mars > >> 2017 13:03 À : jerome brauge Cc : MariaDB Developers > >> (maria-developers(a)lists.launchpad.net) > >> Objet : Re: MDEV-10598 - bb-10.2-compatibility > >> > >> Hello Jerome, > >> > >> > >> On 03/14/2017 06:07 PM, jerome brauge wrote: > >>> Hi Alexander, > >>> Can you review this patch ? > >>> I could add more tests when your others points will be corrected. > >> > >> I tried to simplify your patch slightly. > >> > >> sp_instr_cpush instructions are now created from the array > >> sp_pcontext::m_cursors, which already stores all cursors declared on > >> the current frame. > >> > >> So there is now no a need for a separate list sp_head::m_delayed_cpush. > >> > >> This seems to work fine. > >> > >> Also, I changed the meaning of the last argument of > >> sp_declare_cursor() to the opposite: from "delay_instr" to > "add_cpush_instr". > >> I find "bool do_something" easier to read than "bool > >> dont_do_something", especially in this context: > >> > >> if (do_something) > >> > >> vs > >> > >> if (!dont_do_something) > >> > >> > >> but this is probably my personal preference :) > >> > >> Also I removed overloading (and fixed sql_yacc.yy instead). > >> > >> > >> Can you please review the attached patch? > >> > >> (It also includes my previous suggestions) > >> > >> Many thanks!!! > >> > >>> > >>> Thanks. > >>> Jérôme. > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : mardi 14 > >>>> mars > >>>> 2017 11:54 À : jerome brauge Cc : MariaDB Developers > >>>> (maria-developers(a)lists.launchpad.net) > >>>> Objet : Re: MDEV-10598 - bb-10.2-compatibility > >>>> > >>>> Hi Jerome, > >>>> > >>>> On 03/14/2017 02:29 PM, jerome brauge wrote: > >>>>> Thanks Alexander, > >>>>> > >>>>> I have two other problems to finalize my patch: > >>>>> - Attached script cur_err_warning.sql produce a warning 1931 > >>>>> (Query > >>>> execution was interrupted. The query examined at least 2 rows, > >>>> which exceeds LIMIT ROWS EXAMINED (0). The query result may be > >>>> incomplete) and I don't see why. > >>>> > >>>> That's my fault. Please ignore this warning for now. > >>>> This warning happens when the procedure opens a cursor to resolve > >>>> its structure. I will suppress this warning later. > >>>> > >>>> > >>>>> > >>>>> - Attached script cur_err_field_name.sql produce an error 4057 > >>>>> (HY000) at > >>>> line 23: Row variable 'rec2' does not have a field 'a' > >>>> > >>>> This is also my bug. > >>>> The problem is that rec2 has a name "rec1.a" instead of just "a". > >>>> > >>>> > >>>> > >>>> Please change > >>>> > >>>> CURSOR cur2 IS SELECT rec1.a ; > >>>> > >>>> to > >>>> > >>>> CURSOR cur2 IS SELECT rec1.a AS a; > >>>> > >>>> > >>>>> > >>>>> These two scripts work fine on oracle. > >>>>> > >>>>> Jérôme. > >>>>> > >>>>> > >>>>>> -----Message d'origine----- > >>>>>> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : mardi 14 > >>>>>> mars > >>>>>> 2017 11:11 À : jerome brauge Objet : Re: MDEV-10598 - > >>>>>> bb-10.2-compatibility > >>>>>> > >>>>>> Hello Jerome, > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 03/13/2017 07:46 PM, jerome brauge wrote: > >>>>>>> Alexander, > >>>>>>> I think there is a little bug with ROWTYPE: when I affect a > >>>>>>> variable with a > >>>>>> field value, the server crash. > >>>>>>> I attached the script which cause the issue. > >>>>>> > >>>>>> Thanks for reporting this. > >>>>>> > >>>>>> > >>>>>> This quick patch fixes the problem: > >>>>>> > >>>>>> > >>>>>> diff --git a/sql/sp_head.cc b/sql/sp_head.cc index > >>>>>> faf9f5f..745f982 > >>>>>> 100644 > >>>>>> --- a/sql/sp_head.cc > >>>>>> +++ b/sql/sp_head.cc > >>>>>> @@ -347,6 +347,12 @@ Item * > >>>>>> sp_prepare_func_item(THD* thd, Item **it_addr, uint cols) { > >>>>>> DBUG_ENTER("sp_prepare_func_item"); > >>>>>> + if (!(*it_addr)->fixed && > >>>>>> + (*it_addr)->fix_fields(thd, it_addr)) { > >>>>>> + DBUG_PRINT("info", ("fix_fields() failed")); > >>>>>> + DBUG_RETURN(NULL); > >>>>>> + } > >>>>>> it_addr= (*it_addr)->this_item_addr(thd, it_addr); > >>>>>> > >>>>>> if ((!(*it_addr)->fixed && > >>>>>> > >>>>>> > >>>>>> > >>>>>> But I'm still thinking. > >>>>>> Perhaps I'll end some with some different patch. > >>>>>> I let you know when the final fix is pushed. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> This is the call stack : > >>>>>>> > >>>>>>>> mysqld.exe!my_sigabrt_handler(int sig) Line 477 C > >>>>>>> mysqld.exe!raise(int signum) Line 516 C++ > >>>>>>> mysqld.exe!abort() Line 64 C++ > >>>>>>> mysqld.exe!common_assert_to_stderr_direct(const wchar_t > >> * const > >>>>>> expression, const wchar_t * const file_name, const unsigned int > >>>>>> line_number) Line 124 C++ > >>>>>>> mysqld.exe!common_assert_to_stderr<wchar_t>(const > >> wchar_t * > >>>>>> const expression, const wchar_t * const file_name, const unsigned > int > >>>>>> line_number) Line 138 C++ > >>>>>>> mysqld.exe!common_assert<wchar_t>(const wchar_t * > >> const > >>>>>> expression, const wchar_t * const file_name, const unsigned int > >>>>>> line_number, void * const return_address) Line 383 C++ > >>>>>>> mysqld.exe!_wassert(const wchar_t * expression, const > >> wchar_t * > >>>>>> file_name, unsigned int line_number) Line 404 C++ > >>>>>>> > >> mysqld.exe!Item_splocal_row_field_by_name::this_item_addr(THD > >>>>>> * thd, Item * * it) Line 1814 C++ > >>>>>>> mysqld.exe!sp_prepare_func_item(THD * thd, Item * * > >> it_addr, > >>>>>> unsigned int cols) Line 350 C++ > >>>>>>> mysqld.exe!sp_eval_expr(THD * thd, Item * result_item, > >> Field * > >>>>>> result_field, Item * * expr_item_ptr) Line 391 C++ > >>>>>>> mysqld.exe!sp_rcontext::set_variable(THD * thd, unsigned > >> int > >>>>>>> idx, > >>>>>> Item * * value) Line 566 C++ > >>>>>>> mysqld.exe!sp_instr_set::exec_core(THD * thd, unsigned int > >> * > >>>>>> nextp) Line 3378 C++ > >>>>>>> mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core(THD > >> * thd, > >>>>>> unsigned int * nextp, bool open_tables, sp_instr * instr) Line > >>>>>> 3097 > >> C++ > >>>>>>> mysqld.exe!sp_instr_set::execute(THD * thd, unsigned int * > >>>>>>> nextp) > >>>>>> Line 3371 C++ > >>>>>>> mysqld.exe!sp_head::execute(THD * thd, bool > >>>>>> merge_da_on_success) Line 1261 C++ > >>>>>>> mysqld.exe!sp_head::execute_procedure(THD * thd, > >> List<Item> * > >>>>>> args) Line 2086 C++ > >>>>>>> mysqld.exe!do_execute_sp(THD * thd, sp_head * sp) Line > >> 2890 > >>>>>> C++ > >>>>>>> mysqld.exe!mysql_execute_command(THD * thd) Line 5919 > >> C++ > >>>>>>> mysqld.exe!mysql_parse(THD * thd, char * rawbuf, unsigned > >> int > >>>>>> length, Parser_state * parser_state, bool is_com_multi, bool > >>>>>> is_next_command) Line 8006 C++ > >>>>>>> mysqld.exe!dispatch_command(enum_server_command > >> command, > >>>>>> THD * thd, char * packet, unsigned int packet_length, bool > >> is_com_multi, > >>>>>> bool is_next_command) Line 1821 C++ > >>>>>>> mysqld.exe!do_command(THD * thd) Line 1369 C++ > >>>>>>> mysqld.exe!threadpool_process_request(THD * thd) Line > >> 346 > >>>>>> C++ > >>>>>>> mysqld.exe!tp_callback(TP_connection * c) Line 192 C++ > >>>>>>> mysqld.exe!tp_callback(_TP_CALLBACK_INSTANCE * > >> instance, void * > >>>>>> context) Line 377 C++ > >>>>>>> mysqld.exe!work_callback(_TP_CALLBACK_INSTANCE * > >> instance, > >>>>>> void * context, _TP_WORK * work) Line 451 C++ > >>>>>>> > >>>>>>> Can you reproduce this ? > >>>>>>> > >>>>>>> Jérôme. > >>>>>>> > >>>>>>>> -----Message d'origine----- > >>>>>>>> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : lundi > >>>>>>>> 13 mars > >>>>>>>> 2017 14:47 À : jerome brauge Objet : Re: MDEV-10598 - > >>>>>>>> bb-10.2-compatibility > >>>>>>>> > >>>>>>>> Jérôme, > >>>>>>>> > >>>>>>>> On 03/13/2017 05:43 PM, jerome brauge wrote: > >>>>>>>>> Hello Alexander, > >>>>>>>>> I have to do some changes in the patch and add some tests > >>>>>>>>> cases (with row type) I think it will be ready this afternoon (CET). > >>>>>>>> > >>>>>>>> Excellent. You rock! > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Jérôme. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Message d'origine----- > >>>>>>>>>> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : lundi > >>>>>>>>>> 13 mars > >>>>>>>>>> 2017 14:38 À : jerome brauge Cc : maria-developers Objet : Re: > >>>>>>>>>> MDEV-10598 - bb-10.2-compatibility > >>>>>>>>>> > >>>>>>>>>> Hello Jerome, > >>>>>>>>>> > >>>>>>>>>> will you try to apply your patch on top of the current > >>>>>>>>>> bb-10.2- > >>>>>>>> compatibility? > >>>>>>>>>> > >>>>>>>>>> Or should I do that? > >>>>>>>>>> > >>>>>>>>>> Thanks! > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 03/10/2017 02:36 PM, Alexander Barkov wrote: > >>>>>>>>>>> Hello Jerome, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 02/27/2017 11:39 PM, jerome brauge wrote: > >>>>>>>>>>>> Hello Alexander, > >>>>>>>>>>>> Thanks for the explanation. > >>>>>>>>>>>> It's something we do not use. I did not think about it. > >>>>>>>>>>>> I look forward to your patch. > >>>>>>>>>>> > >>>>>>>>>>> I pushed these tasks: > >>>>>>>>>>> > >>>>>>>>>>> MDEV-10581 sql_mode=ORACLE: Explicit cursor FOR LOOP > >>>>>>>>>>> MDEV-12098 sql_mode=ORACLE: Implicit cursor FOR loop > >>>>>>>>>>> MDEV-12011 sql_mode=ORACLE: cursor%ROWTYPE in variable > >>>>>>>> declarations > >>>>>>>>>>> MDEV-12133 sql_mode=ORACLE: table%ROWTYPE in variable > >>>>>>>> declarations > >>>>>>>>>>> > >>>>>>>>>>> Please clone the branch again. > >>>>>>>>>>> Git pull will not work, because I recently rebased > >>>>>>>>>>> bb-10.2-compatibility on top of the latest 10.2. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> When implementing cursor%ROWTYPE, I had your patch in > mind > >>>> and > >>>>>>>> made > >>>>>>>>>>> some refactoring to help us apply MDEV-10598 easier. > >>>>>>>>>>> Please see a comment to MDEV-12011 in "git log". > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Now the tricky thing (when adding your patch) is to make > >>>>>>>>>>> sure that this work fine: > >>>>>>>>>>> > >>>>>>>>>>> CREATE PROCEDURE p1 > >>>>>>>>>>> AS > >>>>>>>>>>> a INT:=10; > >>>>>>>>>>> CURSOR cur1 IS SELECT a; > >>>>>>>>>>> rec1 cur1%ROWTYPE; > >>>>>>>>>>> CURSOR cur2 IS SELECT rec1.a; > >>>>>>>>>>> rec2 cur2%ROWTYPE; > >>>>>>>>>>> BEGIN > >>>>>>>>>>> OPEN cur2; > >>>>>>>>>>> FETCH cur2 INTO rec2; > >>>>>>>>>>> CLOSE cur2; > >>>>>>>>>>> SELECT rec2.a; > >>>>>>>>>>> END; > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I.e. a set of intermixed CURSOR and cursor%ROWTYPE > variable > >>>>>>>>>>> declarations referencing each other recursively. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> Jérôme. > >>>>>>>>>>>> > >>>>>>>>>>>>> -----Message d'origine----- De : Alexander Barkov > >>>>>>>>>>>>> [mailto:bar@mariadb.org] Envoyé : > >>>>>>>>>>>>> lundi > >>>>>>>>>>>>> 27 février 2017 11:28 À : jerome brauge Cc : > >>>>>>>>>>>>> maria-developers > >>>> Objet : > >>>>>>>>>>>>> Re: MDEV-10598 - bb-10.2-compatibility > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hello Jerome, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 02/21/2017 07:18 PM, jerome brauge wrote: > >>>>>>>>>>>>>> Hello Alexander, > >>>>>>>>>>>>>> I've done this patch for MDEV-10598. > >>>>>>>>>>>>>> Can you review it ? > >>>>>>>>>>>>> > >>>>>>>>>>>>> It seems we'll have to postpone this patch. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm currently working on: > >>>>>>>>>>>>> > >>>>>>>>>>>>> MDEV-10598 Variable declarations can go after cursor > >>>>>>>>>>>>> declarations > >>>>>>>>>>>>> MDEV-12011 sql_mode=ORACLE: cursor%ROWTYPE in > variable > >>>>>>>>>> declarations > >>>>>>>>>>>>> So the trick with postponing variable declarations using a > >>>>>>>>>>>>> temporary list might not work properly after adding > >>>>>>>>>>>>> MDEV-10598 abd MDEV-12011, the order of cursors and > >> variables is important. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Example: > >>>>>>>>>>>>> > >>>>>>>>>>>>> DECLARE > >>>>>>>>>>>>> CURSOR cur1 IS SELECT a,b FROM t1; > >>>>>>>>>>>>> v cur1%ROWTYPE; > >>>>>>>>>>>>> CURSOR cur2 IS SELECT v.a, v.b FROM DUAL; BEGIN > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> END; > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> So the order of cur1, v and cur2 is important. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'll let you known when I'm ready with %ROWTYPE tasks. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> Jérôme. > >>>>>>>>>>>>>>

2 1

Re: [Maria-developers] 85058bf: MDEV-9255 Add generation_expression to information_schema.columns.
by Sergei Golubchik 22 Mar '17

22 Mar '17

Hi, Alexey! On Mar 22, Alexey Botchkov wrote: > revision-id: 85058bf17953dc313731f4b22f0ec6037380f42b (mariadb-10.2.4-77-g85058bf) > parent(s): 1ca8637ae35061d2567728a1c7aede11e68e5fff > committer: Alexey Botchkov > timestamp: 2017-03-22 01:31:47 +0400 > message: > > MDEV-9255 Add generation_expression to information_schema.columns. > > Added IS_GENERATED and GENERATION_EXPRESSION columns required by > the SQL standard. Ouch, 1M for a commit email for a few-liner... > revision-id: 85058bf17953dc313731f4b22f0ec6037380f42b (mariadb-10.2.4-77-g85058bf) > parent(s): 1ca8637ae35061d2567728a1c7aede11e68e5fff > committer: Alexey Botchkov > timestamp: 2017-03-22 01:31:47 +0400 > message: > > MDEV-9255 Add generation_expression to information_schema.columns. > > diff --git a/mysql-test/suite/funcs_1/r/is_columns.result b/mysql-test/suite/funcs_1/r/is_columns.result > index 63c6e11..382a634 100644 > --- a/mysql-test/suite/funcs_1/r/is_columns.result > +++ b/mysql-test/suite/funcs_1/r/is_columns.result > @@ -70,7 +72,9 @@ COLUMNS CREATE TEMPORARY TABLE `COLUMNS` ( > `COLUMN_KEY` varchar(3) NOT NULL DEFAULT '', > `EXTRA` varchar(30) NOT NULL DEFAULT '', > `PRIVILEGES` varchar(80) NOT NULL DEFAULT '', > - `COLUMN_COMMENT` varchar(1024) NOT NULL DEFAULT '' > + `COLUMN_COMMENT` varchar(1024) NOT NULL DEFAULT '', > + `IS_GENERATED` varchar(6) NOT NULL DEFAULT '', > + `GENERATION_EXPRESSION` varchar(766) DEFAULT NULL does it mean that longer expressions will be truncated? we suport up to 64K expressions. should this be SMALLTEXT or long varchar, perhaps? > ) DEFAULT CHARSET=utf8 > SHOW COLUMNS FROM information_schema.COLUMNS; > Field Type Null Key Default Extra > diff --git a/mysql-test/suite/gcol/t/gcol_bugfixes.test b/mysql-test/suite/gcol/t/gcol_bugfixes.test > index 7ca50e6..1318abe 100644 > --- a/mysql-test/suite/gcol/t/gcol_bugfixes.test > +++ b/mysql-test/suite/gcol/t/gcol_bugfixes.test > @@ -536,3 +536,17 @@ SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ; > SELECT 1 FROM t WHERE c GROUP BY b; > COMMIT; > DROP TABLE t; > + > +--echo # > +--echo # MDEV-9255 Add generation_expression to information_schema.columns. > +--echo # > + > +CREATE TABLE gcol_t1 ( > + sidea DOUBLE, > + sideb DOUBLE, > + sidec DOUBLE AS (SQRT(sidea * sidea + sideb * sideb)) > +); > + > +SELECT * FROM information_schema.columns WHERE table_name='gcol_t1'; Great. Just one tiny detail - there is no gcol_bugfixes.result in your commit :) > + > +DROP TABLE gcol_t1; Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] MDEV-10598 - bb-10.2-compatibility
by jerome brauge 22 Mar '17

22 Mar '17

Thanks Alexander, I have two other problems to finalize my patch: - Attached script cur_err_warning.sql produce a warning 1931 (Query execution was interrupted. The query examined at least 2 rows, which exceeds LIMIT ROWS EXAMINED (0). The query result may be incomplete) and I don't see why. - Attached script cur_err_field_name.sql produce an error 4057 (HY000) at line 23: Row variable 'rec2' does not have a field 'a' These two scripts work fine on oracle. Jérôme. > -----Message d'origine----- > De : Alexander Barkov [mailto:bar@mariadb.org] > Envoyé : mardi 14 mars 2017 11:11 > À : jerome brauge > Objet : Re: MDEV-10598 - bb-10.2-compatibility > > Hello Jerome, > > > > On 03/13/2017 07:46 PM, jerome brauge wrote: > > Alexander, > > I think there is a little bug with ROWTYPE: when I affect a variable with a > field value, the server crash. > > I attached the script which cause the issue. > > Thanks for reporting this. > > > This quick patch fixes the problem: > > > diff --git a/sql/sp_head.cc b/sql/sp_head.cc index faf9f5f..745f982 100644 > --- a/sql/sp_head.cc > +++ b/sql/sp_head.cc > @@ -347,6 +347,12 @@ Item * > sp_prepare_func_item(THD* thd, Item **it_addr, uint cols) { > DBUG_ENTER("sp_prepare_func_item"); > + if (!(*it_addr)->fixed && > + (*it_addr)->fix_fields(thd, it_addr)) { > + DBUG_PRINT("info", ("fix_fields() failed")); > + DBUG_RETURN(NULL); > + } > it_addr= (*it_addr)->this_item_addr(thd, it_addr); > > if ((!(*it_addr)->fixed && > > > > But I'm still thinking. > Perhaps I'll end some with some different patch. > I let you know when the final fix is pushed. > > > > > > This is the call stack : > > > >> mysqld.exe!my_sigabrt_handler(int sig) Line 477 C > > mysqld.exe!raise(int signum) Line 516 C++ > > mysqld.exe!abort() Line 64 C++ > > mysqld.exe!common_assert_to_stderr_direct(const wchar_t * const > expression, const wchar_t * const file_name, const unsigned int > line_number) Line 124 C++ > > mysqld.exe!common_assert_to_stderr<wchar_t>(const wchar_t * > const expression, const wchar_t * const file_name, const unsigned int > line_number) Line 138 C++ > > mysqld.exe!common_assert<wchar_t>(const wchar_t * const > expression, const wchar_t * const file_name, const unsigned int > line_number, void * const return_address) Line 383 C++ > > mysqld.exe!_wassert(const wchar_t * expression, const wchar_t * > file_name, unsigned int line_number) Line 404 C++ > > mysqld.exe!Item_splocal_row_field_by_name::this_item_addr(THD > * thd, Item * * it) Line 1814 C++ > > mysqld.exe!sp_prepare_func_item(THD * thd, Item * * it_addr, > unsigned int cols) Line 350 C++ > > mysqld.exe!sp_eval_expr(THD * thd, Item * result_item, Field * > result_field, Item * * expr_item_ptr) Line 391 C++ > > mysqld.exe!sp_rcontext::set_variable(THD * thd, unsigned int idx, > Item * * value) Line 566 C++ > > mysqld.exe!sp_instr_set::exec_core(THD * thd, unsigned int * > nextp) Line 3378 C++ > > mysqld.exe!sp_lex_keeper::reset_lex_and_exec_core(THD * thd, > unsigned int * nextp, bool open_tables, sp_instr * instr) Line 3097 C++ > > mysqld.exe!sp_instr_set::execute(THD * thd, unsigned int * nextp) > Line 3371 C++ > > mysqld.exe!sp_head::execute(THD * thd, bool > merge_da_on_success) Line 1261 C++ > > mysqld.exe!sp_head::execute_procedure(THD * thd, List<Item> * > args) Line 2086 C++ > > mysqld.exe!do_execute_sp(THD * thd, sp_head * sp) Line 2890 > C++ > > mysqld.exe!mysql_execute_command(THD * thd) Line 5919 C++ > > mysqld.exe!mysql_parse(THD * thd, char * rawbuf, unsigned int > length, Parser_state * parser_state, bool is_com_multi, bool > is_next_command) Line 8006 C++ > > mysqld.exe!dispatch_command(enum_server_command command, > THD * thd, char * packet, unsigned int packet_length, bool is_com_multi, > bool is_next_command) Line 1821 C++ > > mysqld.exe!do_command(THD * thd) Line 1369 C++ > > mysqld.exe!threadpool_process_request(THD * thd) Line 346 > C++ > > mysqld.exe!tp_callback(TP_connection * c) Line 192 C++ > > mysqld.exe!tp_callback(_TP_CALLBACK_INSTANCE * instance, void * > context) Line 377 C++ > > mysqld.exe!work_callback(_TP_CALLBACK_INSTANCE * instance, > void * context, _TP_WORK * work) Line 451 C++ > > > > Can you reproduce this ? > > > > Jérôme. > > > >> -----Message d'origine----- > >> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : lundi 13 mars > >> 2017 14:47 À : jerome brauge Objet : Re: MDEV-10598 - > >> bb-10.2-compatibility > >> > >> Jérôme, > >> > >> On 03/13/2017 05:43 PM, jerome brauge wrote: > >>> Hello Alexander, > >>> I have to do some changes in the patch and add some tests cases > >>> (with row type) I think it will be ready this afternoon (CET). > >> > >> Excellent. You rock! > >> > >>> > >>> Jérôme. > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : lundi 13 > >>>> mars > >>>> 2017 14:38 À : jerome brauge Cc : maria-developers Objet : Re: > >>>> MDEV-10598 - bb-10.2-compatibility > >>>> > >>>> Hello Jerome, > >>>> > >>>> will you try to apply your patch on top of the current bb-10.2- > >> compatibility? > >>>> > >>>> Or should I do that? > >>>> > >>>> Thanks! > >>>> > >>>> > >>>> On 03/10/2017 02:36 PM, Alexander Barkov wrote: > >>>>> Hello Jerome, > >>>>> > >>>>> > >>>>> On 02/27/2017 11:39 PM, jerome brauge wrote: > >>>>>> Hello Alexander, > >>>>>> Thanks for the explanation. > >>>>>> It's something we do not use. I did not think about it. > >>>>>> I look forward to your patch. > >>>>> > >>>>> I pushed these tasks: > >>>>> > >>>>> MDEV-10581 sql_mode=ORACLE: Explicit cursor FOR LOOP > >>>>> MDEV-12098 sql_mode=ORACLE: Implicit cursor FOR loop > >>>>> MDEV-12011 sql_mode=ORACLE: cursor%ROWTYPE in variable > >> declarations > >>>>> MDEV-12133 sql_mode=ORACLE: table%ROWTYPE in variable > >> declarations > >>>>> > >>>>> Please clone the branch again. > >>>>> Git pull will not work, because I recently rebased > >>>>> bb-10.2-compatibility on top of the latest 10.2. > >>>>> > >>>>> > >>>>> When implementing cursor%ROWTYPE, I had your patch in mind and > >> made > >>>>> some refactoring to help us apply MDEV-10598 easier. > >>>>> Please see a comment to MDEV-12011 in "git log". > >>>>> > >>>>> > >>>>> Now the tricky thing (when adding your patch) is to make sure that > >>>>> this work fine: > >>>>> > >>>>> CREATE PROCEDURE p1 > >>>>> AS > >>>>> a INT:=10; > >>>>> CURSOR cur1 IS SELECT a; > >>>>> rec1 cur1%ROWTYPE; > >>>>> CURSOR cur2 IS SELECT rec1.a; > >>>>> rec2 cur2%ROWTYPE; > >>>>> BEGIN > >>>>> OPEN cur2; > >>>>> FETCH cur2 INTO rec2; > >>>>> CLOSE cur2; > >>>>> SELECT rec2.a; > >>>>> END; > >>>>> > >>>>> > >>>>> I.e. a set of intermixed CURSOR and cursor%ROWTYPE variable > >>>>> declarations referencing each other recursively. > >>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Jérôme. > >>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> De : Alexander Barkov [mailto:bar@mariadb.org] Envoyé : lundi 27 > >>>>>>> février 2017 11:28 À : jerome brauge Cc : maria-developers Objet : > >>>>>>> Re: MDEV-10598 - bb-10.2-compatibility > >>>>>>> > >>>>>>> Hello Jerome, > >>>>>>> > >>>>>>> > >>>>>>> On 02/21/2017 07:18 PM, jerome brauge wrote: > >>>>>>>> Hello Alexander, > >>>>>>>> I've done this patch for MDEV-10598. > >>>>>>>> Can you review it ? > >>>>>>> > >>>>>>> It seems we'll have to postpone this patch. > >>>>>>> > >>>>>>> I'm currently working on: > >>>>>>> > >>>>>>> MDEV-10598 Variable declarations can go after cursor > >>>>>>> declarations > >>>>>>> MDEV-12011 sql_mode=ORACLE: cursor%ROWTYPE in variable > >>>> declarations > >>>>>>> So the trick with postponing variable declarations using a > >>>>>>> temporary list might not work properly after adding MDEV-10598 > >>>>>>> abd MDEV-12011, the order of cursors and variables is important. > >>>>>>> > >>>>>>> Example: > >>>>>>> > >>>>>>> DECLARE > >>>>>>> CURSOR cur1 IS SELECT a,b FROM t1; > >>>>>>> v cur1%ROWTYPE; > >>>>>>> CURSOR cur2 IS SELECT v.a, v.b FROM DUAL; BEGIN > >>>>>>> ... > >>>>>>> END; > >>>>>>> > >>>>>>> > >>>>>>> So the order of cur1, v and cur2 is important. > >>>>>>> > >>>>>>> I'll let you known when I'm ready with %ROWTYPE tasks. > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Jérôme. > >>>>>>>>

2 9

Re: [Maria-developers] 1ee6b0ff748: MDEV-11115 CHECK constraints are not shown in I_S.TABLE_CONSTRAINTS
by Sergei Golubchik 21 Mar '17

21 Mar '17

Hi, jacob.mathew! On Mar 16, jacob.mathew(a)mariadb.com wrote: > revision-id: 1ee6b0ff74858dccd779c7974858c6d084c1cde5 (mariadb-10.2.3-246-g1ee6b0ff748) > parent(s): 9f33288dde950343c46e6c5d6a4f233de191f477 > author: Jacob Mathew > committer: Jacob Mathew > timestamp: 2017-03-16 18:31:11 -0700 > message: > > MDEV-11115 CHECK constraints are not shown in I_S.TABLE_CONSTRAINTS > > Fixed handling of column-level CHECK constraints in I_S.TABLE_CONSTRAINTS. > Fixed a bug regarding virtual column definitions whose name is the field name. > Fixed column-level CHECK constraint syntax in the test case. Ah, good. I had a feeling there was something wrong with field-level constraints in your first patch. This looks great now. Did you push it into a stage tree already? Like bb-10.2-jacob or something? If not - please do. If you did and buildbot didn't show anything bad, please squash your three commits into one, rebase it on top of the current 10.2 and push. Thanks! Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

3 4

Re: [Maria-developers] [Commits] 06dac6f23f6: MDEV-10355 Weird error message upon CREATE TABLE with DEFAULT
by Sergei Golubchik 21 Mar '17

21 Mar '17

Hi, Jacob! Even if MDEV is not "In Review", here're few early thoughts to consider: On Mar 20, jacob.mathew(a)mariadb.com wrote: > revision-id: 06dac6f23f662d6892fddd47c4566c96a3d044d3 (mariadb-10.2.3-180-g06dac6f23f6) > parent(s): cd53525d7c97a7c2b69873fbbd28982844e3cae3 > author: Jacob Mathew > committer: Jacob Mathew > timestamp: 2017-03-20 16:35:31 -0700 > message: > > MDEV-10355 Weird error message upon CREATE TABLE with DEFAULT > > Fixed handling of default values with BETWEEN and temporal functions. > Added test case. > > diff --git a/mysql-test/r/func_default_between_temporal.result b/mysql-test/r/func_default_between_temporal.result > new file mode 100644 > index 00000000000..a1d11f56d4d > --- /dev/null > +++ b/mysql-test/r/func_default_between_temporal.result > @@ -0,0 +1,11 @@ > +CREATE OR REPLACE TABLE t1 ( col INT DEFAULT ( 1 LIKE ( NOW() BETWEEN '2000-01-01' AND '2012-12-12' ) ) ); > +SHOW CREATE TABLE t1; > +Table Create Table > +t1 CREATE TABLE `t1` ( > + `col` int(11) DEFAULT (1 like (current_timestamp() between 2000-01-01 00:00:00 and 2012-12-12 00:00:00)) Note, that the generated create table statement is invalid. Temporal constants are printed unquoted. > +) ENGINE=MyISAM DEFAULT CHARSET=latin1 > +INSERT INTO t1 VALUES( DEFAULT ); > +SELECT * FROM t1; > +col > +0 > +DROP TABLE t1; > diff --git a/sql/item.cc b/sql/item.cc > index dd2c4fd75a5..5c0afc526f8 100644 > --- a/sql/item.cc > +++ b/sql/item.cc > @@ -9378,17 +9378,30 @@ void Item_cache::store(Item *item) > > void Item_cache::print(String *str, enum_query_type query_type) > { > - if (value_cached) > - { > - print_value(str); > - return; > - } > - str->append(STRING_WITH_LEN("<cache>(")); > - if (example) > - example->print(str, query_type); > - else > - Item::print(str, query_type); > - str->append(')'); > + if ( ( query_type & QT_ITEM_ORIGINAL_FUNC_NULLIF ) && > + example && ( example->type() == FUNC_ITEM ) ) > + { > + // Instead of "cache" or the cached value, print the function name, > + // which is more meaningful to the end user > + const char *func_name = ( ( Item_func* ) example )->func_name(); > + > + str->append( func_name ); > + str->append( "()" ); 1. Why a check for QT_ITEM_ORIGINAL_FUNC_NULLIF? Is it how you distinguish SHOW CREATE from EXPLAIN? 2. Why do you do that explicitly, instead of example->print()? The item knows how to print itself. You don't. For example, the function can have arguments, not "()", or may be it needs to be printed using infix notation (like Item_func_plus, and some others). > + } > + else > + { > + if (value_cached) > + { > + print_value(str); > + return; > + } > + str->append(STRING_WITH_LEN("<cache>(")); > + if (example) > + example->print(str, query_type); > + else > + Item::print(str, query_type); > + str->append(')'); > + } Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] Google Summer of Code
by Daniel Black 20 Mar '17

20 Mar '17

I got referred to another GSoC documentation site: https://code.timvideos.us/summer-of-code/ I think its a pretty good model of what sort of documentation students should read as largely it applies to projects in general.

1 0

Re: [Maria-developers] 23959479689: MDEV-11419: Report all INSERT ID for bulk operation INSERT
by Sergei Golubchik 20 Mar '17

20 Mar '17

Hi, Oleksandr! On Jan 17, Oleksandr Byelkin wrote: > revision-id: 23959479689f47bdfe5aa33cb6cd5e1171b5f8a8 (mariadb-10.2.2-128-g23959479689) > parent(s): 9ea5de30963dd16cec7190b8b2f77858f4a82545 > committer: Oleksandr Byelkin > timestamp: 2017-01-17 15:47:17 +0100 > message: > > MDEV-11419: Report all INSERT ID for bulk operation INSERT > > Send all Insert IDs of the buld operation to client (JDBC need it) > > --- > include/mysql.h.pp | 3 +- > include/mysql_com.h | 3 +- > sql/protocol.cc | 22 +++++++--- > sql/protocol.h | 6 +++ > sql/sql_class.cc | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > sql/sql_class.h | 8 ++++ > sql/sql_insert.cc | 11 ++++- > sql/sql_prepare.cc | 21 ++++++++-- Tests are in C/C repository, I hope? > diff --git a/include/mysql_com.h b/include/mysql_com.h > index c399520022d..9fac5edd1bc 100644 > --- a/include/mysql_com.h > +++ b/include/mysql_com.h > @@ -551,7 +551,8 @@ enum enum_cursor_type > CURSOR_TYPE_NO_CURSOR= 0, > CURSOR_TYPE_READ_ONLY= 1, > CURSOR_TYPE_FOR_UPDATE= 2, > - CURSOR_TYPE_SCROLLABLE= 4 > + CURSOR_TYPE_SCROLLABLE= 4, > + INSERT_ID_REQUEST= 128 That's very weird. Why would "INSERT_ID_REQUEST" be a flag in the "cursor_type"? Don't put this flag into enum_cursor_type > }; > > > diff --git a/sql/protocol.cc b/sql/protocol.cc > index f8b68c02fff..608c06da2df 100644 > --- a/sql/protocol.cc > +++ b/sql/protocol.cc > @@ -562,6 +562,7 @@ void Protocol::end_statement() > > switch (thd->get_stmt_da()->status()) { > case Diagnostics_area::DA_ERROR: > + thd->stop_collecting_insert_id(); > /* The query failed, send error to log and abort bootstrap. */ > error= send_error(thd->get_stmt_da()->sql_errno(), > thd->get_stmt_da()->message(), > @@ -573,12 +574,21 @@ void Protocol::end_statement() > break; > case Diagnostics_area::DA_OK: > case Diagnostics_area::DA_OK_BULK: > - error= send_ok(thd->server_status, > - thd->get_stmt_da()->statement_warn_count(), > - thd->get_stmt_da()->affected_rows(), > - thd->get_stmt_da()->last_insert_id(), > - thd->get_stmt_da()->message(), > - thd->get_stmt_da()->skip_flush()); > + if (thd->report_collected_insert_id()) > + if (thd->is_error()) > + error= send_error(thd->get_stmt_da()->sql_errno(), > + thd->get_stmt_da()->message(), > + thd->get_stmt_da()->get_sqlstate()); > + else > + error= send_eof(thd->server_status, > + thd->get_stmt_da()->statement_warn_count()); > + else > + error= send_ok(thd->server_status, > + thd->get_stmt_da()->statement_warn_count(), > + thd->get_stmt_da()->affected_rows(), > + thd->get_stmt_da()->last_insert_id(), > + thd->get_stmt_da()->message(), > + thd->get_stmt_da()->skip_flush()); > break; > case Diagnostics_area::DA_DISABLED: > break; > diff --git a/sql/protocol.h b/sql/protocol.h > index 6397e3dd5e6..bf74f52fa98 100644 > --- a/sql/protocol.h > +++ b/sql/protocol.h > @@ -30,6 +30,12 @@ class Item_param; > typedef struct st_mysql_field MYSQL_FIELD; > typedef struct st_mysql_rows MYSQL_ROWS; > > +struct insert_id_desc > +{ > + ulonglong first_id; > + ulonglong sequence; > +}; > + > class Protocol > { > protected: > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index 8fabc8f593e..53591c371c0 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -1474,6 +1474,7 @@ void THD::init(void) > #endif //EMBEDDED_LIBRARY > > apc_target.init(&LOCK_thd_data); > + insert_ids= NULL; > DBUG_VOID_RETURN; > } > > @@ -7365,4 +7366,119 @@ bool Discrete_intervals_list::append(Discrete_interval *new_interval) > DBUG_RETURN(0); > } > > +bool THD::init_collecting_insert_id() > +{ > + if (!insert_ids) > + { > + void *buff; > + if (!(my_multi_malloc(MYF(MY_WME), &insert_ids, sizeof(DYNAMIC_ARRAY), > + &buff, sizeof(insert_id_desc) * 10, > + NullS)) || > + my_init_dynamic_array2(insert_ids, sizeof(insert_id_desc), > + buff, 10, 100, MYF(MY_WME))) Huh? 1. You allocate DYNAMIC_ARRAY, on the heap, for every (insert-id generating) statement. Why? 2. You preallocate a buffer, but dynamic array cannot reallocate it, so on the 11'th element, it'll allocate *another* buffer and won't use yours. Better: put DYNAMIC_ARRAY in the THD, or (even better) allocate it with thd->alloc. And let DYNAMIC_ARRAY do it's own memory management. > + { > + if (insert_ids) > + my_free(insert_ids); > + insert_ids= NULL; > + return TRUE; > + } > + collect_auto_increment_increment= variables.auto_increment_increment; > + } > + return FALSE; > +} > + > +void THD::stop_collecting_insert_id() > +{ > + if (insert_ids) > + { > + delete_dynamic(insert_ids); > + my_free(insert_ids); > + insert_ids= NULL; > + } > +} > + > +bool THD::collect_insert_id(ulonglong id) > +{ > + if (insert_ids) > + { > + if (insert_ids->elements) > + { > + insert_id_desc *last= > + (insert_id_desc *)dynamic_array_ptr(insert_ids, > + insert_ids->elements - 1); > + if (id == last->first_id) > + { > + return FALSE; // no new insert id > + } > + if (id == last->first_id + (last->sequence * > + collect_auto_increment_increment)) > + { > + last->sequence++; > + return FALSE; > + } > + } > + insert_id_desc el; > + el.first_id= id; > + el.sequence= 1; > + if (insert_dynamic(insert_ids, &el)) > + { > + return TRUE; > + } > + } > + return FALSE; > +} This definitely needs a comment, explaining what you're doing and how you're storing your insert id values. > + > + > +bool THD::report_collected_insert_id() > +{ > + if (insert_ids) > + { > + List<Item> field_list; > + MEM_ROOT tmp_mem_root; > + Query_arena arena(&tmp_mem_root, Query_arena::STMT_INITIALIZED), backup; > + > + init_alloc_root(arena.mem_root, 2048, 4096, MYF(0)); > + set_n_backup_active_arena(&arena, &backup); > + DBUG_ASSERT(mem_root == &tmp_mem_root); > + > + field_list.push_back(new (mem_root) > + Item_int(this, "Id", 0, MY_INT64_NUM_DECIMAL_DIGITS), > + mem_root); > + field_list.push_back(new (mem_root) > + Item_int(this, "Len", 0, MY_INT64_NUM_DECIMAL_DIGITS), > + mem_root); > + field_list.push_back(new (mem_root) > + Item_return_int(this, "Inc", 0, MYSQL_TYPE_LONG), > + mem_root); > + > + if (protocol_binary.send_result_set_metadata(&field_list, > + Protocol::SEND_NUM_ROWS | Protocol::SEND_EOF)) > + goto error; > + > + for (ulonglong i= 0; i < insert_ids->elements; i++) > + { > + insert_id_desc *last= > + (insert_id_desc *)dynamic_array_ptr(insert_ids, i); > + if (insert_ids->elements == 1 && last->first_id == 0 && > + get_stmt_da()->affected_rows() != 1) > + continue; // No insert IDs > + protocol_binary.prepare_for_resend(); > + protocol_binary.store_longlong(last->first_id, TRUE); > + protocol_binary.store_longlong(last->sequence, TRUE); > + protocol_binary.store_long(collect_auto_increment_increment); > + if (protocol_binary.write()) > + goto error; > + } > +error: > + restore_active_arena(&arena, &backup); > + DBUG_ASSERT(arena.mem_root == &tmp_mem_root); > + // no need free Items because they was only constants > + free_root(arena.mem_root, MYF(0)); > + stop_collecting_insert_id(); > + return TRUE; > + } > + return FALSE; > + > +} > + > #endif /* !defined(MYSQL_CLIENT) */ > diff --git a/sql/sql_insert.cc b/sql/sql_insert.cc > index 7c0c1b68a2b..20b775c9273 100644 > --- a/sql/sql_insert.cc > +++ b/sql/sql_insert.cc > @@ -1007,6 +1007,12 @@ bool mysql_insert(THD *thd,TABLE_LIST *table_list, > } > its.rewind(); > iteration++; > + > + if (!error && thd->bulk_param) > + { > + thd->collect_insert_id(table->file->insert_id_for_cur_row); > + } 1. Why are you doing it here, and not per row, inside `while ((values= its++))` loop? 2. What about INSERT ... SELECT? 3. What about a insert-id generated in one statement but for many tables? (stored function, trigger, whatever) > + > } while (iteration < bulk_iterations); Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

3 4

Re: [Maria-developers] b6f4d16: MDEV-10436 non-deterministic vcol does not force rbr
by Sergei Golubchik 20 Mar '17

20 Mar '17

Hi, Sachin! On Feb 10, Sachin Setiya wrote: > revision-id: b6f4d16a015fc778186ae4d2c1820a78cd9645d1 (mariadb-10.2.3-157-gb6f4d16) > parent(s): 5285504857df6caf417c8a56601913a95c9f7abc > author: Sachin Setiya > committer: Sachin Setiya > timestamp: 2017-02-10 18:24:12 +0530 > message: > > MDEV-10436 non-deterministic vcol does not force rbr > > Problem:- Since 10.2.1 one can create virtual generated columns with > non-deterministic functions. Arguably, in cases like > INSERT t1 SELECT * FROM t2 > if t2 contains such non-deterministic generated columns and replication > mode is MIXED, the statement should be logged in the row format. But it is > logged in statement format. Some explanation of the fix would be good here. Especially if it's not trivial. Why did you need set_cs_bin_format_row_if_mixed_and_nd_vcol() function and why are you doing something in end_send()? You've fixed THD::decide_logging_format(), why was that not enough? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 2

[Maria-developers] MDEV-12303 Add Type_handler::Item_xxx_fix_length_and_dec()
by Alexander Barkov 20 Mar '17

20 Mar '17

Hello Alexey, Can you please review a patch for MDEV-12303? Thanks!

1 0