- developers - lists.mariadb.org

Re: [Maria-developers] 8cd65cd: MDEV-9143 JSON_xxx functions.
by Sergei Golubchik 08 Oct '16

08 Oct '16

Hi, Alexey! On Sep 21, Alexey Botchkov wrote: > > > > + In the worst case one character from the 'a' string > > > + turns into '\uXXXX\uXXXX' which is 12. > > > how comes? add an example, please. Like "for example, character x'1234' > > in the charset A becomes '\u1234\u5678' if JSON string is in the charset B" > > For instance the 'SMILING FACE WITH SUNGLASSES' character, > which is utf32(0001F60E) should be represented as \uD83D\uDE0E. I hope you put this in the comment in the code... Other comments, that you didn't reply to, does it mean you agree with them (like adding tests with values that need json-escaping)? Okay. Thanks for unit tests. There weren't many, but if you think they cover all the library functionality, then it's fine. Just one thought - do you expect any more json_lib related test *files* in the future? If not, you could move json_lib-t.cc into unittest/strings. And why the test is .cc? The file looked pure C to me. Anyway, I think it's ok to push after resolving these minor issues. Thanks! Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] 1c9da8d: MDEV-9312: storage engine not enforced during galera cluster replication
by Jan Lindström 29 Sep '16

29 Sep '16

Hi Nirbhay, This looks ok but one question (no need to change now): On Wed, Sep 28, 2016 at 7:36 PM, Nirbhay Choubey <nirbhay(a)mariadb.com> wrote: > > + Since some wsrep threads (THDs) are create before plugins are > + initialized, LOCK_plugin mutex needs to be initialized here. > + */ > Is there some fundamental reason why we can't create wsrep threads after other plugins and related global system variables (that are really needed for wsrep) are initialized ? R: Jan

2 1

Re: [Maria-developers] [Commits] a8162d4: MDEV-9312: storage engine not enforced during galera cluster replication
by Sergei Golubchik 28 Sep '16

28 Sep '16

Hi, Nirbhay! I don't understand, why do you need to create a dummy plugin here? On Sep 27, Nirbhay Choubey wrote: > revision-id: a8162d4a8737cff67889390fad0153acc175391d (mariadb-10.1.17-22-ga8162d4) > parent(s): 6a6b253a6ecbd4d3dd254044d12ec64475453275 > author: Nirbhay Choubey > committer: Nirbhay Choubey > timestamp: 2016-09-27 09:03:26 -0400 > message: > > MDEV-9312: storage engine not enforced during galera cluster replication > > Perform a post initialization of plugin-related variables > of wsrep threads after their global counterparts have been > initialized. ... > +#ifdef WITH_WSREP > + > +/* > + Placeholder for global_system_variables.table_plugin required during > + initialization of startup wsrep threads. > +*/ > +static st_plugin_int *wsrep_dummy_plugin; > + > +/* > + Initialize wsrep_dummy_plugin and assign it to > + global_system_variables.table_plugin. > +*/ > +void wsrep_plugins_pre_init() > +{ > + wsrep_dummy_plugin= > + (st_plugin_int *) my_malloc(sizeof(st_plugin_int), MYF(0)); > + wsrep_dummy_plugin->state= PLUGIN_IS_DISABLED; > + global_system_variables.table_plugin= plugin_int_to_ref(wsrep_dummy_plugin); > +} > + Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 2

Re: [Maria-developers] 12ffe70: MDEV-9416: MariaDB galera got signal 11 when altering table add unique index
by Sergei Golubchik 28 Sep '16

28 Sep '16

Hi, Nirbhay! On Sep 24, Nirbhay Choubey wrote: > revision-id: 12ffe70831c9c69c3d6ef83431443696455c332b (mariadb-10.1.17-23-g12ffe70) > parent(s): 8ffded0a78c0a4912b32acac4c3f58f04c3bcd87 > author: Nirbhay Choubey > committer: Nirbhay Choubey > timestamp: 2016-09-24 00:27:38 -0400 > message: > > MDEV-9416: MariaDB galera got signal 11 when altering table add unique index > > When a BF thread attempts to abort a victim thread's transaction, > the victim thread is not locked and thus its not safe to rely on > its data structures like htons registered for the trx. > > So, instead of getting the registered htons from victim, innodb's > hton can be looked up directly from installed_htons[] and used to > abort the transaction. (Same technique is used in older versions) > > diff --git a/sql/handler.cc b/sql/handler.cc > index 4e4c8fa..6a32fec 100644 > --- a/sql/handler.cc > +++ b/sql/handler.cc > @@ -6108,29 +6108,16 @@ int ha_abort_transaction(THD *bf_thd, THD *victim_thd, my_bool signal) > DBUG_RETURN(0); > } > > - /* Try statement transaction if standard one is not set. */ > - THD_TRANS *trans= (victim_thd->transaction.all.ha_list) ? > - &victim_thd->transaction.all : &victim_thd->transaction.stmt; > - > - Ha_trx_info *ha_info= trans->ha_list, *ha_info_next; > - > - for (; ha_info; ha_info= ha_info_next) > + handlerton *hton= installed_htons[DB_TYPE_INNODB]; > + if (hton && hton->abort_transaction) > { > - handlerton *hton= ha_info->ht(); > - if (!hton->abort_transaction) > - { > - /* Skip warning for binlog & wsrep. */ > - if (hton->db_type != DB_TYPE_BINLOG && hton != wsrep_hton) > - { > - WSREP_WARN("Cannot abort transaction."); > - } > - } > - else > - { > - hton->abort_transaction(hton, bf_thd, victim_thd, signal); > - } > - ha_info_next= ha_info->next(); > + hton->abort_transaction(hton, bf_thd, victim_thd, signal); Okay, but please add a comment that it's safe to abort from one thread (bf_thd) the transaction, running in another thread (victim_thd), because innodb's lock_sys and trx_mutex guarantee the necessary protection. And that it's not safe to access victim_thd->transaction, because it's not protected from concurrent accesses. And it's an overkill to take LOCK_plugin and iterate the whole installed_htons[] array every time. Then ok to push > } > + else > + { > + WSREP_WARN("Cannot abort InnoDB transaction"); > + } > + > DBUG_RETURN(0); > } Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] f2aea43: MDEV-10649: Optimizer sometimes use "index" instead of "range" access for UPDATE
by Jan Lindström 28 Sep '16

28 Sep '16

On Tue, Sep 6, 2016 at 8:37 PM, Sergei Petrunia <psergey(a)askmonty.org> wrote: > revision-id: f2aea435df7e92fcf8f09f8f6c160161168c5bed > parent(s): a14f61ef749ad9f9ab2b0f5badf6754ba7443c9e > committer: Sergei Petrunia > branch nick: 10.0 > timestamp: 2016-09-06 20:37:21 +0300 > message: > > MDEV-10649: Optimizer sometimes use "index" instead of "range" access for > UPDATE > > (XtraDB variant only, for now) > > Re-opening a TABLE object (after e.g. FLUSH TABLES or open table cache > eviction) causes ha_innobase to call > dict_stats_update(DICT_STATS_FETCH_ONLY_IF_NOT_IN_MEMORY). > > Inside this call, the following is done: > dict_stats_empty_table(table); > dict_stats_copy(table, t); > > On the other hand, commands like UPDATE make this call to get the "rows in > table" statistics in table->stats.records: > > ha_innobase->info(HA_STATUS_VARIABLE|HA_STATUS_NO_LOCK) > > note the HA_STATUS_NO_LOCK parameter. It means, no locks are taken by > ::info() If the ::info() call happens between dict_stats_empty_table > and dict_stats_copy calls, the UPDATE's optimizer will get an estimate > of table->stats.records=1, which causes it to pick a full table scan, > which in turn will take a lot of row locks and cause other bad > consequences. > > --- > storage/xtradb/dict/dict0stats.cc | 29 +++++++++++++++++++---------- > 1 file changed, 19 insertions(+), 10 deletions(-) > > diff --git a/storage/xtradb/dict/dict0stats.cc b/storage/xtradb/dict/ > dict0stats.cc > index b073398..a4aa436 100644 > --- a/storage/xtradb/dict/dict0stats.cc > +++ b/storage/xtradb/dict/dict0stats.cc > @@ -673,7 +673,10 @@ Write all zeros (or 1 where it makes sense) into a > table and its indexes' > dict_stats_copy( > /*============*/ > dict_table_t* dst, /*!< in/out: destination table */ > - const dict_table_t* src) /*!< in: source table */ > + const dict_table_t* src, /*!< in: source table */ > + bool reset_ignored_indexes) /*!< in: if true, set ignored > indexes > + to have the same statistics > as if > + the table was empty */ > { > dst->stats_last_recalc = src->stats_last_recalc; > dst->stat_n_rows = src->stat_n_rows; > @@ -692,7 +695,16 @@ Write all zeros (or 1 where it makes sense) into a > table and its indexes' > && (src_idx = dict_table_get_next_index(src_idx)))) { > > if (dict_stats_should_ignore_index(dst_idx)) { > - continue; > + if (reset_ignored_indexes) { > + /* Reset index statistics for all ignored > indexes, > + unless they are FT indexes (these have no > statistics)*/ > + if (dst_idx->type & DICT_FTS) { > + continue; > + } > + dict_stats_empty_index(dst_idx); > Does this really help? Yes, we hold dict_sys mutex here so dict_stats_empty_index here is safe for all readers using same mutex. However, as you pointed up above, info() uses no locking method. Thus, we really do not know what it will return, all values before dict_stats_copy(), some of the indexes with new stats, all indexes with new stats. > > @@ -3240,13 +3252,10 @@ N*AVG(Ui). In each call it searches for the > currently fetched index into > > dict_table_stats_lock(table, RW_X_LATCH); > > - /* Initialize all stats to dummy values before > - copying because dict_stats_table_clone_create() > does > - skip corrupted indexes so our dummy object 't' may > - have less indexes than the real object 'table'. */ > - dict_stats_empty_table(table); > - > - dict_stats_copy(table, t); > + /* Pass reset_ignored_indexes=true as parameter > + to dict_stats_copy. This will cause statictics > + for corrupted indexes to be set to empty values */ > + dict_stats_copy(table, t, true); > This is better solution than the original but as noted above, is this enough ? R: Jan

2 2

[Maria-developers] Review for MDEV-6112 multiple triggers per table
by Alexander Barkov 28 Sep '16

28 Sep '16

Hello Monty. I checked your patch for MDEV-6112 multiple triggers per table. Here are some quick notes. I'll send a detailed review separately. 1. It would be nice to push refactoring changes in separate patch: a. do sql_mode_t refactoring b. "trg_idx -> Trigger *" refactoring c. opt_debugging related things 2. Why not to reuse the FOLLOWING_SYM and PRECEDING_SYM keywords instead of adding new ones FOLLOWS_SYM, PRECEDES_SYM ? (this is a non-standard syntax anyway) 3. I'd prefer PRECEDES/FOLLOWS to go before FOR EACH ROW. "FOR EACH ROW stmt" is a kind of single clause responsible for the action. It's very confusing to have PRECEDES/FOLLOWS characteristics in between "FOR EACH ROW" and stmt. 4. You have a lot of changes related to trim_whitespace() where you declare an unused "prefix_removed" variable. It would be nice to avoid declaring it. Possible ways: a. Perhaps the new function version can be defined like this: size_t trim_whitespace(CHARSET_INFO *cs, LEX_STRING *str); and make it return "prefix length removed", instead of adding a new parameter. b. Another option is just to overload it: extern void trim_whitespace(CHARSET_INFO *cs, LEX_STRING *str, uint *prefix_removed); inline void trim_whitespace(CHARSET_INFO *cs, LEX_STRING *str) { uint not_used; trim_whitespace(cs, str, &not_used); } 5. The "CREATED" field is not populated well. I'm getting strange values like 1970-04-24 09:35:00.30. Btw, his query returns a correct value: SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(CREATED)*100) FROM INFORMATION_SCHEMA.triggers; You must have forgotten to multiply or delete to 100 somewhere. 6. In replication tests it's better to make sure that CREATED is safely replicated (instead of changing it to #). By the way, in other tests it's also a good idea not to use # for CREATED. (see the previous problem) You can use this: SET TIMESTAMP=UNIX_TIMESTAMP('2001-01-01 10:20:30'); ... SET TIMESTAM=DEFAULT; 7. I suggest to move this code into a method, say find_trigger(): + if (table->triggers) + { + Trigger *t; + for (t= table->triggers->get_trigger(TRG_EVENT_INSERT, + TRG_ACTION_BEFORE); + t; + t= t->next) + if (t->is_fields_updated_in_trigger(&full_part_field_set)) + DBUG_RETURN(false); + } It's repeated at least two times. 8. The following structure fields are defined two times: enum trigger_order_type ordering_clause; LEX_STRING anchor_trigger_name; The first time for st_trg_chistics. The second time for %union in sql_yacc.yy Note, there will be the third time in sql_yacc_ora.yy. Please define a structure in sql_lex.h instead: struct st_trg_execution_order_chistics { /** FOLLOWS or PRECEDES as specified in the CREATE TRIGGER statement. */ enum trigger_order_type ordering_clause; /** Trigger name referenced in the FOLLOWS/PRECEDES clause of the CREATE TRIGGER statement. */ LEX_STRING anchor_trigger_name; }; and reuse it in here: struct st_trg_chirstics: public st_trg_execution_order_chistics { ... }; and in here: %union { ... st_trg_execition_order_chistics trg_execution_order_chirstics; ... }; Please also rename trg_characteristics to trg_execution_order_chistics, because "trg_characteristics" is more suitable to something having type st_trg_chirstics rather than st_trg_execution_order_chistics. Greetings.

1 1

[Maria-developers] Possibly a problem in "Allowed to use WITH clauses before SELECT in CREATE ... SELECT and INSERT ... SELECT"
by Alexander Barkov 28 Sep '16

28 Sep '16

Hello Igor, I was rebasing bb-10.2-compatibility on top of the latest 10.2 and noticed this grammar change: > create_select_query_specification: > - SELECT_SYM create_select_part2 create_select_part3 create_select_part4 > + SELECT_SYM opt_with_clause create_select_part2 create_select_part3 > + create_select_part4 > + { > + Select->set_with_clause($2); > + } > ; I have some questions: - From my understanding, opt_with_clause should go before SELECT_SYM Why does it go after? - Why this grammar change is not covered in tests? - What is the MDEV number for this change? Thanks!

1 0

Re: [Maria-developers] [Commits] 13b5098: MDEV-9531: GROUP_CONCAT with ORDER BY inside takes a lot of memory while it's executed
by Sergei Golubchik 26 Sep '16

26 Sep '16

Hi, Oleksandr! On Jun 28, Oleksandr Byelkin wrote: > revision-id: 13b5098fcaa888173472d255e29aff22bcc5baae (mariadb-10.1.13-18-g13b5098) > parent(s): 732adec0a4c75d99389230feeb0deca0ad668de7 > committer: Oleksandr Byelkin > timestamp: 2016-06-28 10:59:59 +0200 > message: > > MDEV-9531: GROUP_CONCAT with ORDER BY inside takes a lot of memory while it's executed > > Limitation added to Red-Black tree. > > --- > include/my_tree.h | 14 +++- > mysql-test/r/group_concat_big.result | 6 ++ > mysql-test/t/group_concat_big.result | 6 ++ > mysql-test/t/group_concat_big.test | 6 ++ > mysys/tree.c | 156 ++++++++++++++++++++++++----------- > sql/item_sum.cc | 45 ++++++++-- > 6 files changed, 177 insertions(+), 56 deletions(-) > > diff --git a/include/my_tree.h b/include/my_tree.h > index f8be55f..f1916b9 100644 > --- a/include/my_tree.h > +++ b/include/my_tree.h > @@ -57,11 +57,14 @@ typedef struct st_tree_element { > } TREE_ELEMENT; > > #define ELEMENT_CHILD(element, offs) (*(TREE_ELEMENT**)((char*)element + offs)) > +#define R_ELEMENT_CHILD(element, offs) ((TREE_ELEMENT**)((char*)element + offs)) Please, #define ELEMENT_CHILD_PTR(element, offs) ((TREE_ELEMENT**)((char*)element + offs)) #define ELEMENT_CHILD(element, offs) (*ELEMENT_CHILD_PTR(element, offs)) > typedef struct st_tree { > TREE_ELEMENT *root,null_element; > TREE_ELEMENT **parents[MAX_TREE_HEIGHT]; > + TREE_ELEMENT *free_element; > uint offset_to_key,elements_in_tree,size_of_element; > + uint elements_limit, del_direction; > size_t memory_limit, allocated; > qsort_cmp2 compare; > void *custom_arg; > diff --git a/mysql-test/r/group_concat_big.result b/mysql-test/r/group_concat_big.result > new file mode 100644 > index 0000000..4de0ebb > --- /dev/null > +++ b/mysql-test/r/group_concat_big.result > @@ -0,0 +1,6 @@ > +SELECT GROUP_CONCAT( seq, seq, seq, seq, seq, seq, seq, seq ORDER BY > +2,1,3,4,6,5,8,7 ) AS cfield1 FROM seq_1_to_50000000; > +cfield1 > +11111111,22222222,33333333,44444444,55555555,66666666,77777777,88888888,99999999,1010101010101010,1111111111111111,1212121212121212,1313131313131313,1414141414141414,1515151515151515,1616161616161616,1717171717171717,1818181818181818,1919191919191919,2020202020202020,2121212121212121,2222222222222222,2323232323232323,2424242424242424,2525252525252525,2626262626262626,2727272727272727,2828282828282828,2929292929292929,3030303030303030,3131313131313131,3232323232323232,3333333333333333,3434343434343434,3535353535353535,3636363636363636,3737373737373737,3838383838383838,3939393939393939,4040404040404040,4141414141414141,4242424242424242,4343434343434343,4444444444444444,4545454545454545,4646464646464646,4747474747474747,4848484848484848,4949494949494949,5050505050505050,5151515151515151,5252525252525252,5353535353535353,5454545454545454,5555555555555555,5656565656565656,5757575757575757,5858585858585858,5959595959595959,6060606060606060,6161616161616161,6262626262626262,6363636 > 363636363,6464646464646464,65656565 > +Warnings: > +Warning 1260 Row 65 was cut by GROUP_CONCAT() 1. Same result without your patch? 2. I suppose all rows after 65 skipped completely, aren't they? > diff --git a/mysql-test/t/group_concat_big.result b/mysql-test/t/group_concat_big.result > new file mode 100644 > index 0000000..4de0ebb > --- /dev/null > +++ b/mysql-test/t/group_concat_big.result > @@ -0,0 +1,6 @@ > +SELECT GROUP_CONCAT( seq, seq, seq, seq, seq, seq, seq, seq ORDER BY > +2,1,3,4,6,5,8,7 ) AS cfield1 FROM seq_1_to_50000000; > +cfield1 > +11111111,22222222,33333333,44444444,55555555,66666666,77777777,88888888,99999999,1010101010101010,1111111111111111,1212121212121212,1313131313131313,1414141414141414,1515151515151515,1616161616161616,1717171717171717,1818181818181818,1919191919191919,2020202020202020,2121212121212121,2222222222222222,2323232323232323,2424242424242424,2525252525252525,2626262626262626,2727272727272727,2828282828282828,2929292929292929,3030303030303030,3131313131313131,3232323232323232,3333333333333333,3434343434343434,3535353535353535,3636363636363636,3737373737373737,3838383838383838,3939393939393939,4040404040404040,4141414141414141,4242424242424242,4343434343434343,4444444444444444,4545454545454545,4646464646464646,4747474747474747,4848484848484848,4949494949494949,5050505050505050,5151515151515151,5252525252525252,5353535353535353,5454545454545454,5555555555555555,5656565656565656,5757575757575757,5858585858585858,5959595959595959,6060606060606060,6161616161616161,6262626262626262,6363636 > 363636363,6464646464646464,65656565 > +Warnings: > +Warning 1260 Row 65 was cut by GROUP_CONCAT() Interesting. How did you manage to include the same file twice in a commit diff? > diff --git a/mysys/tree.c b/mysys/tree.c > index a9fc542..6c094d9 100644 > --- a/mysys/tree.c > +++ b/mysys/tree.c > @@ -157,6 +172,10 @@ static void free_tree(TREE *tree, myf free_flags) > free_root(&tree->mem_root, free_flags); > } > } > + if (tree->free_element && tree->with_delete && tree->free) > + (*tree->free)(tree->free_element, free_free, > + tree->custom_arg); "&& tree->with_delete" is wrong here > + tree->free_element= 0; > tree->root= &tree->null_element; > tree->elements_in_tree=0; > tree->allocated=0; > @@ -190,6 +209,42 @@ static void delete_tree_element(TREE *tree, TREE_ELEMENT *element) > } > function comment would be nice here > +void tree_exclude(TREE *tree, TREE_ELEMENT ***parent) > +{ > + int remove_colour; > + TREE_ELEMENT ***org_parent, *nod; > + TREE_ELEMENT *element= **parent; > @@ -202,7 +257,32 @@ TREE_ELEMENT *tree_insert(TREE *tree, void *key, uint key_size, > void* custom_arg) > { > int cmp; > - TREE_ELEMENT *element,***parent; > + TREE_ELEMENT *element, ***parent; > + > + if (tree->elements_limit && tree->elements_in_tree && no need for "&& tree->elements_in_tree" > + tree->elements_in_tree >= tree->elements_limit) > + { > + /* > + The limit reached so we should remove one. > + It is done on the very beginning because: > + 1) "parents" will be used > + 2) removing make incorrect search pass what does that mean? > + If we will not insert now, we leave freed element for future use > + */ > + DBUG_ASSERT(key_size == 0); why? > + > + parent= tree->parents; > + *parent = &tree->root; element= tree->root; > + while (element != &tree->null_element) > + { > + *++parent= R_ELEMENT_CHILD(element, tree->del_direction); > + element= ELEMENT_CHILD(element, tree->del_direction); > + } > + parent--; > + tree->free_element= **parent; > + tree_exclude(tree, parent); > + tree->elements_in_tree--; > + } > > parent= tree->parents; > *parent = &tree->root; element= tree->root; > diff --git a/sql/item_sum.cc b/sql/item_sum.cc > index 1cfee1a..8bcc2ce 100644 > --- a/sql/item_sum.cc > +++ b/sql/item_sum.cc > @@ -3390,7 +3390,7 @@ Item_func_group_concat::fix_fields(THD *thd, Item **ref) > fixed= 1; > return FALSE; > } > - > +struct tree_node_size {void *left,*right; uint32 f;}; why do you need that? > > bool Item_func_group_concat::setup(THD *thd) > { > @@ -3499,17 +3499,50 @@ bool Item_func_group_concat::setup(THD *thd) > > if (arg_count_order) > { > + uint min_rec_length= 1; //at least 1 byte per rec (coma) > + { > + List_iterator_fast<Item> li(all_fields); > + Item *item; > + while ((item= li++)) > + { > + switch (item->result_type()) > + { > + case STRING_RESULT: > + break; // could be empty string > + case DECIMAL_RESULT: > + case REAL_RESULT: > + min_rec_length+=2; > + break; > + case INT_RESULT: > + min_rec_length++; > + break; > + case TIME_RESULT: > + min_rec_length+=6; > + break; > + default: > + case ROW_RESULT: > + DBUG_ASSERT(0); > + break; > + } > + } > + } yeah... that'll work, of course, but for strings (most common case) you'll allocates tens or hundreds (if not thousands) times more memory than needed :( A hackish workaround could be to adjust tree->elements_limit (in Item_func_group_concat::add) after each insertion. But in this case it would be simpler to limit the tree by size (in bytes) and adjust tree size after each insertion. What do you think about it? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 3

[Maria-developers] mysql_get_timeout_value returning 0 always
by Gonzalo Diethelm 24 Sep '16

24 Sep '16

I am basing my work on the async_queries.c example. In my code, I am calling mysql_real_connect_start(), and the return value indicates that MySQL is waiting for READ and TIMEOUT. However, if I call mysql_get_timeout_value() (or the _ms() version) right after that, it returns 0. Is this expected? As far as I can see, this is causing the next call to mysql_real_connect_cont() (which happens immediately, because the timeout triggers right away) to return an error. This is on OS X 10.11.6 with the MariaDB client just installed via brew; mariadb_config --version says 5.5.1. This is the code I'm calling: status = mysql_real_connect_start(&ret, &mysql, h, u, p, d, 0, 0, 0); printf("MYSQL connect %d", status); if (status & MYSQL_WAIT_TIMEOUT) { unsigned int ms = mysql_get_timeout_value_ms(&mysql); printf(" and includes a timeout of %u ms", ms); } printf("\n"); That code prints: MYSQL connect 9 and includes a timeout of 0 ms I did find two ways to make the code work: 1. Not passing MYSQL_WAIT_TIMEOUT back to the mysql_real_connect_cont() (so it thinks a timeout has not happened at all). This allows all the queries to actually complete, but the code ends up polling heavily. 2. Forcing the return value of mysql_get_timeout_value_ms() to be > 0. This makes the code work beautifully, but of course I would rather follow MySQL's hint as to the timeout extension. I would appreciate any hints as to what I am missing. Thanks much in advance. -- Gonzalo Diethelm gonzalo.diethelm(a)gmail.com

2 4

Re: [Maria-developers] 8ffded0: MDEV-9312: storage engine not enforced during galera cluster replication
by Sergei Golubchik 24 Sep '16

24 Sep '16

Hi, Nirbhay! On Sep 24, Nirbhay Choubey wrote: > diff --git a/sql/sql_plugin.cc b/sql/sql_plugin.cc > index 60248f3..99b3311 100644 > --- a/sql/sql_plugin.cc > +++ b/sql/sql_plugin.cc > @@ -3116,7 +3118,12 @@ void plugin_thdvar_init(THD *thd) > thd->variables.dynamic_variables_size= 0; > thd->variables.dynamic_variables_ptr= 0; > > - if (IF_WSREP((!WSREP(thd) || !thd->wsrep_applier),1)) > + /* > + The following initializations are deferred for some wsrep system threads > + created during startup as they could be created even before LOCK_plugin > + and plugins are initialized. > + */ > + if (IF_WSREP((plugins_are_initialized),1)) why do you need that? I think you can safely call plugin_thdvar_init() twice, so you don't really need to skip the first invocation. It's that principle that the one reponsible for the problem should pay for it, others shouldn't suffer :) In ha_maria:implicit_commit, it was Aria's hack, and that if() was added inside Aria. Here is purely wsrep problem, putting an if() on a common code path for all threads looks just wrong. > { > mysql_mutex_lock(&LOCK_plugin); > thd->variables.table_plugin= Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0