- developers - lists.mariadb.org

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

Re: [Maria-developers] Filtered transactions coming through mysql/mariadb replication to Galera cluster
by Michael Widenius 20 Mar '17

20 Mar '17

Hi! > Hi, > > Galera cluster (https://github.com/codership/mysql-wsrep/commits/5.6) has new feature : > > commit 14301279075dc2b420f3173cc9c2eb7912db63de > Author: sjaakola <seppo.jaakola(a)iki.fi> > Date: Fri Nov 18 12:45:42 2016 +0200 > > Refs: MW-319 > * replicating write set containing only GTID event of totally filtered transaction > coming in through mysql replication > * note that replicated WS will have no keys, and current debug version of Galera 3.19 > will assert for no keys > > My questions: > > (1) If MySQL (5.6/5.7) replicates transactions to Galera cluster (assuming here that this cluster will contain MariaDB 10.0-10.2 nodes) does the server somehow see filtered GTID events ? > > (2) If MariaDB replicates transactions to Galera cluster are filtered transactions seen by Galera ? What exactly is the definition of filtered transactions? In MariaDB replication, we automatically remove all MySQL GTID's and what the slaves sees is basically a replication stream without any GTID, like it would come from an old slave. The slave will add it's own GTID's to it's own binary log, if logging is enabled. Seppo, is this still the case for new Galera code that will come to MariaDB? If not, what has changed? Regards, Monty

1 0

[Maria-developers] [GSOC] Table functions (aka SQL functions returning tables)
by Pranjal Rai 20 Mar '17

20 Mar '17

Hello, My name is Pranjal and I am a 4th year student at IIIT Hyderabad. I am interested in working on the project MDEV-8100 <https://jira.mariadb.org/browse/MDEV-8100> "Table functions (aka SQL functions returning tables)". I read the description of the task and it is quite clear to me. In the comments it is advised to consider creating TABLE datatype for the task. Is this task along with creation of TABLE datatype doable in the given timeline? Also, can someone please suggest what part of the source code should I read. Regards, Pranjal

2 1

[Maria-developers] prospective GSOC 2017 student [MDEV-7502]
by ibrar arshad 19 Mar '17

19 Mar '17

Hi, My name is Ibrar Arshad and I am interested in working on the task of automatic slave provisioning(ticket: MDEV-7502 <https://jira.mariadb.org/browse/MDEV-7502>) during GSOC 2017. I have read the summary on the ticket and have achieved a fair understanding of the problem and I am working towards ironing out the implementation details. The use-case as I understand is that we want the slave to auto-replicate the data from master once pointed the master and we want to do it in such a manner that the binlog events from current master position as well as the old data chunks are relayed to the slave in a parallel fashion. I have a few questions related to the proposal: 1. After reading a few pages on replication, my understanding is that after "CHANGE MASTER TO" and "START SLAVE", master starts sending binlog events from its current position to the slave which slave starts applying. The usual replication approach is to get the current binlog position on master, backup all the data till this position from master to slave, point slave to this position(or GTID) via "CHANGE MASTER TO", and START SLAVE to start replicating bin events from master. But for MDEV-7502, we want the normal events and old data chunks to be transmitted in parallel. The ticket summary mentions using separate domain_ids to send the new and old data in parallel, does there exist a way to do so currently? How can domain id be used here? Can we currently point the slave to 2 different bin positions on a single master and expect the master to send events from both positions? Or will this require some sort of new process/thread implementation on master to do so? 2. There are at-least two other approaches mentioned in the ticket's comments section. It doesn't seem like that a single approach has been finalized. This project doesn't seem to have a mentor yet to provide guidance so which approach should an applicant pursue further? I would like to discuss the project approaches and implementation further in detail before submitting a proposal so can somebody please answer my queries and further suggest pointers to this project specific material which I can go through to get a deeper understanding? Thanks.

3 2