- developers - lists.mariadb.org

[Maria-developers] MDEV-4309, second patch: review
by Sergei Petrunia 29 Jan '14

29 Jan '14

Hello, This is a review for MDEV-4309, second patch: https://mariadb.atlassian.net/secure/attachment/21510/201303271828_sanja_co… === The name "memcmp_func" is confusing, because the function has nothing to do with memcmp. Did you mean memcpy actually? The function should be renamed to something like "memcpy_field_value". memcmp_func() still makes one virtual call. === Consider a scenario: - Item_field::setup_cpy_optimizer() is called. - It calls memcmp_possible(), which returns FALSE, which means field_conv() will be called for every row. - field_conv() will still call memcpy_field_value(), even if we know that it will return false. Why not add a field_conv_incompatible() and make field_conv look like this: find_conv() { if (memcmp_possible()) { ... } return field_conv_incompatible(); } === The name "cpy_optimizer" is very cryptic. Is "Fast_field_copier" better? === class Item_field has this member: Field *cpy_optimizer_setup; I don't see how it is useful without its corresponding 'cpy_optimizer' data. cpy_optimizer is only present inside ORDER structure which has both: cpy_optimizer cpy_optimizer_func; Field *cpy_optimizer_setup; If ORDER has both members, why have the Item_field::cpy_optimizer_setup ? === Let's discuss this on IRC. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] single thread performance (was: Re: Need to check if the slowdown is still there)
by Sergei Petrunia 29 Jan '14

29 Jan '14

Hi Axel, On Tue, Jan 28, 2014 at 04:27:10PM +0100, Axel Schwenke wrote: > Hi, > > I have now re-run a benchmark to test single thread performance. This is the > continuation of MDEV-4309. > Thanks for the data. > ... > The numbers demonstrate quite clearly the general observation that with each > new major version of MariaDB/MySQL the code path becomes longer and the > performance suffers. But there is also good news: sometimes during the > maturing of a release the performance may increase again. I.e. I have seen > significant changes from MySQL-5.6.13 to 5.6.14. I agree with the observations. I would even say that MySQL was getting worse in 5.6.11 - 5.6.13 versions, and then fixe something in 5.6.14. > Also from MariaDB-5.5.30 to > 5.5.31 (which was when MDEV-4309 was implemented). Unfortunately between > MariaDB-5.5.33 and 5.5.34 most of that was lost again :( The first step in not letting that happen is to have the benchmark data so that we know if there are any problems. The patch for MDEV-4309 part#2 is not yet ready. We will get back to you when it can be used for testing. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] The "Monty Program AB" vendor check (rpm)
by Oden Eriksson 28 Jan '14

28 Jan '14

Hello, I got assigned to look at the rpm packaging and fixed some stuff there, but got stuck at the "Monty Program AB" vendor check in support-files/rpm/server- prein.sh when I wanted to replace the fedora packages with in this case mariadb galera packages. Is this check absolutely nessesary? This prevents you from an easy switch from the fedora mariadb packages to the ones provided by mariadb using yum and a yum repository as provided at http://yum.mariadb.org/. Basically this check prevents me from doing any serious work with the rpm packages because you manually have to, by force deinstall any conflicting packages and then install the packages provided by us. Cheers.

3 3

Re: [Maria-developers] Review request for a fix for MDEV-5506
by Sergei Golubchik 28 Jan '14

28 Jan '14

Hi, Alexander! Few questions, see below. > === modified file 'mysql-test/t/timezone2.test' > --- mysql-test/t/timezone2.test 2013-08-08 08:58:28 +0000 > +++ mysql-test/t/timezone2.test 2014-01-23 10:34:46 +0000 > @@ -298,5 +298,11 @@ SELECT CONVERT_TZ(TIME('00:00:00'),'+00: > SELECT CONVERT_TZ(TIME('2010-01-01 00:00:00'),'+00:00','+7:5'); > > --echo # > +--echo # MDEV-5506 safe_mutex: Trying to lock unitialized mutex at safemalloc.c on server shutdown after SELECT with CONVERT_TZ > +--echo # > +SELECT CONVERT_TZ('2001-10-08 00:00:00', MAKE_SET(0,'+01:00'), '+00:00' ); hmm, the bug description was "at shutdown". I don't see a shutdown in your test case. I suppose, you assume that the server will be eventually shut down and that'll do. But perhaps it needs to be shut down immediately, and if mtr will do a lot of work in this server the test case becomes invalid - it won't crash anymore? > === modified file 'sql/item_strfunc.cc' > --- sql/item_strfunc.cc 2013-09-25 12:30:13 +0000 > +++ sql/item_strfunc.cc 2014-01-23 10:17:57 +0000 > @@ -43,7 +43,7 @@ C_MODE_END > /** > @todo Remove this. It is not safe to use a shared String object. > */ I guess, you've fixed that and can remove the comment. > -String my_empty_string("",default_charset_info); > +String_const my_empty_string("", default_charset_info); > > === modified file 'sql/sql_string.h' > --- sql/sql_string.h 2012-11-09 08:11:20 +0000 > +++ sql/sql_string.h 2014-01-23 10:26:13 +0000 > @@ -56,25 +56,52 @@ uint convert_to_printable(char *to, size > > class String > { > + typedef enum > + { > + STRING_FLAG_NONE= 0, > + STRING_FLAG_ALLOCED= 1, > + STRING_FLAG_READ_ONLY= 2, > + STRING_FLAG_NULL_TERMINATED= 4 > + } flag_t; > char *Ptr; > uint32 str_length,Alloced_length, extra_alloc; > - bool alloced; > + flag_t flags; > CHARSET_INFO *str_charset; Okay, I understand what you did. But I don't understand why. What was the problem? Why there was a crash? Regards, Sergei

2 4

[Maria-developers] MariaDB 5.5.35 Release Prep
by Daniel Bartholomew 28 Jan '14

28 Jan '14

All, I've begun the prep work for the MariaDB 5.5.35 release. The draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-5535-changelog/ - https://mariadb.com/kb/en/mariadb-5535-release-notes/ Please let me know ASAP if there's anything that needs to be mentioned/highlighted/removed/etc... The release is still building in buildbot. If all goes well, the plan is to begin uploading the files to the mirrors later today and then to activate the release as soon as most mirrors have picked up the files. Thanks. -- Daniel Bartholomew MariaDB

1 0

[Maria-developers] 5.5.35 Release ?
by ImperialNetwork 27 Jan '14

27 Jan '14

Hi, I was wondering if MariaDB 5.5.35 is going to be released today as stated on jira page. I plan some maintenance and i will do it as soon as 5.5.35 will be released. Thank you in advance Alexandru

2 1

Re: [Maria-developers] Rev 4009: MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES
by Sergei Golubchik 27 Jan '14

27 Jan '14

Hi, Sergey! Ok to push. A couple of comments below: On Jan 27, Sergey Vojtovich wrote: > revno: 4009 > revision-id: svoj(a)mariadb.org-20140127090430-g63lt751yxw9ddud > parent: sergii(a)pisem.net-20131217162654-dw2zlm3td1p12bxl > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5345 > timestamp: Mon 2014-01-27 13:04:30 +0400 > message: > MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > INSTALL PLUGIN > > === modified file 'sql/sql_plugin.cc' > --- a/sql/sql_plugin.cc 2013-12-12 17:14:08 +0000 > +++ b/sql/sql_plugin.cc 2014-01-27 09:04:30 +0000 > @@ -1196,6 +1190,9 @@ static void plugin_deinitialize(struct s > if (ref_check && plugin->ref_count) > sql_print_error("Plugin '%s' has ref_count=%d after deinitialization.", > plugin->name.str, plugin->ref_count); > + > + mysql_del_sys_var_chain(plugin->system_vars); > + restore_pluginvar_names(plugin->system_vars); Can mysql_del_sys_var_chain() be called from inside restore_pluginvar_names() ? They seem always to be called together. > @@ -1342,7 +1335,8 @@ void plugin_unlock_list(THD *thd, plugin > } > > > -static int plugin_initialize(struct st_plugin_int *plugin) > +static int plugin_initialize(MEM_ROOT *tmp_root, struct st_plugin_int *plugin, > + int *argc, char **argv, bool options_only) > { I thought you'll rename a function :) But that's just fine too, whatever you prefer. Regards, Sergei

1 0

Re: [Maria-developers] MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES
by Sergei Golubchik 27 Jan '14

27 Jan '14

Hi, Sergey! Looks ok, see a couple of question (and minor style-related comments) below. On Dec 27, Sergey Vojtovich wrote: > At lp:maria/5.5 > > ------------------------------------------------------------ > revno: 4009 > revision-id: svoj(a)mariadb.org-20131227101419-ahpdahcundclr6gv > parent: sergii(a)pisem.net-20131217162654-dw2zlm3td1p12bxl > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5345 > timestamp: Fri 2013-12-27 14:14:19 +0400 > message: > MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > INSTALL PLUGIN > > There was mixed lock order between LOCK_plugin, LOCK_global_system_variables > and LOCK_system_variables_hash. This patch ensures that write-lock on > LOCK_system_variables_hash doesn't intersect with LOCK_plugin. > > Fixed by moving initialization/deinitialization of plugin options from > plugin_add()/plugin_del() to plugin_initialize()/plugin_deinitalize(). > So that plugin options are handled without protection of LOCK_plugin. > === added file 'mysql-test/r/plugin_vars.result' > --- a/mysql-test/r/plugin_vars.result 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/r/plugin_vars.result 2013-12-27 10:14:19 +0000 > @@ -0,0 +1,22 @@ > +# > +# MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > +# INSTALL PLUGIN > +# > +CREATE PROCEDURE p_install(x INT) > +BEGIN > +DECLARE CONTINUE HANDLER FOR 1126 BEGIN END; > +WHILE x DO > +SET x= x - 1; > +INSTALL PLUGIN no_such_plugin SONAME 'no_such_object'; > +END WHILE; > +END| > +CREATE PROCEDURE p_show_vars(x INT) > +WHILE x DO > +SET x= x - 1; > +SHOW VARIABLES; > +END WHILE| > +CALL p_install(100);; > +CALL p_show_vars(100);; Note two semicolons at the end. The mysqltest syntax is either builtin_command arguments; or --builtin_command arguments I mean, it either ends with a semicolon or starts with dash-dash. Not a big deal, of course :) > +USE test; > +DROP PROCEDURE p_install; > +DROP PROCEDURE p_show_vars; > > === added file 'mysql-test/t/plugin_vars.test' > --- a/mysql-test/t/plugin_vars.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/t/plugin_vars.test 2013-12-27 10:14:19 +0000 > @@ -0,0 +1,56 @@ > +--echo # > +--echo # MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > +--echo # INSTALL PLUGIN > +--echo # > + > +# Prepare test > +delimiter |; > +CREATE PROCEDURE p_install(x INT) > +BEGIN > + DECLARE CONTINUE HANDLER FOR 1126 BEGIN END; > + WHILE x DO > + SET x= x - 1; > + INSTALL PLUGIN no_such_plugin SONAME 'no_such_object'; > + END WHILE; > +END| > + > +CREATE PROCEDURE p_show_vars(x INT) > +WHILE x DO > + SET x= x - 1; > + SHOW VARIABLES; > +END WHILE| > +delimiter ;| > + > +connect(con1, localhost, root,,); > +connect(con2, localhost, root,,); > + > +# Start test > +connection con1; > +--send CALL p_install(100); > + > +connection con2; > +--send CALL p_show_vars(100); Why did you prefer this test over a deterministic one with debug sync points? > +connection default; > + > +disable_result_log; > +let $i= 100; > +while ($i) > +{ > + change_user; > + dec $i; > +} > + > +# Cleanup > +connection con1; > +reap; > +connection con2; > +reap; > +connection default; > +enable_result_log; > + > +disconnect con1; > +disconnect con2; > +USE test; > +DROP PROCEDURE p_install; > +DROP PROCEDURE p_show_vars; > > === modified file 'sql/sql_plugin.cc' > --- a/sql/sql_plugin.cc 2013-12-12 17:14:08 +0000 > +++ b/sql/sql_plugin.cc 2013-12-27 10:14:19 +0000 > @@ -201,7 +202,7 @@ static bool initialized= 0; > write-lock on LOCK_system_variables_hash is required before modifying > the following variables/structures > */ > -static MEM_ROOT plugin_mem_root; > +static MEM_ROOT plugin_vars_mem_root; ok, so you couldn't consistently use one lock for plugin_mem_root, and had to create a second memroot. I see. another option would be to use one memroot and a dedicated lock for it. but I don't think it matters much what solution we use here :) > static uint global_variables_dynamic_size= 0; > static HASH bookmark_hash; > > @@ -1342,7 +1337,8 @@ void plugin_unlock_list(THD *thd, plugin > } > > > -static int plugin_initialize(struct st_plugin_int *plugin) > +static int plugin_initialize(MEM_ROOT *tmp_root, struct st_plugin_int *plugin, > + int *argc, char **argv, bool initialize) this looks pretty weird. plugin_initialize() function that doesn't initialize if its initialize argument is false? perhaps it's better to rename the function then? Or create another one that tests plugin options and invokes plugin_initialize() if necessary? > { > int ret= 1; > DBUG_ENTER("plugin_initialize"); > @@ -1413,6 +1421,14 @@ static int plugin_initialize(struct st_p > ret= 0; > > err: > + if (ret) > + { > + mysql_rwlock_wrlock(&LOCK_system_variables_hash); > + mysql_del_sys_var_chain(plugin->system_vars); > + mysql_rwlock_unlock(&LOCK_system_variables_hash); > + restore_pluginvar_names(plugin->system_vars); may be, you'd move these four lines in a separate function? like, cleanup_plugin_sysvars() ? > + } > + > mysql_mutex_lock(&LOCK_plugin); > plugin->state= state; > > @@ -1646,9 +1654,10 @@ int plugin_init(int *argc, char **argv, > for (i= 0; i < plugin_array.elements; i++) > { > plugin_ptr= *dynamic_element(&plugin_array, i, struct st_plugin_int **); > - if (plugin_ptr->state == PLUGIN_IS_UNINITIALIZED) > + if (plugin_ptr->plugin_dl && plugin_ptr->state == PLUGIN_IS_UNINITIALIZED) Why? > { > - if (plugin_initialize(plugin_ptr)) > + if (plugin_initialize(&tmp_root, plugin_ptr, argc, argv, > + !(flags & PLUGIN_INIT_SKIP_INITIALIZATION))) > { > plugin_ptr->state= PLUGIN_IS_DYING; > *(reap++)= plugin_ptr; Regards, Sergei

2 4

Re: [Maria-developers] Please review MDEV-5458 RQG hits 'sql/tztime.cc:799: my_time_t sec_since_epoch(int, int, int, int, int, int): Assertion `mon > 0 && mon < 13' failed.'
by Sergei Golubchik 27 Jan '14

27 Jan '14

Hi, Alexander! First, please cc: such requests to maria-developers@ instead. Thanks! On Jan 22, Alexander Barkov wrote: > > Please review a patch for a crashing bug MDEV-5458. > > Item_func_min_max::get_date() did not always honor the flags > given (such as NO_ZERO_IN_DATE and NO_ZERO_DATE) > in could erroneously return a not-NULL value instead of NULL. > > The patch moves the call for check_date_with_warn() > *AFTER* conversion from DATETIME to TIME, to make > sure that the returned value always matches the requested > flags. > > Previously it was done before conversion. The value before > conversion could be OK for the flags given, but the value > after conversion could be not OK. > > Also, I added a new function adjust_time_range_with_warn() > to avoid duplicate code. Reused it in three places. All ok. Just one comment: > === modified file 'sql/mysql_priv.h' > --- sql/mysql_priv.h 2013-12-02 11:09:34 +0000 > +++ sql/mysql_priv.h 2014-01-22 14:53:38 +0000 > @@ -2582,6 +2582,7 @@ check_date(const MYSQL_TIME *ltime, ulon > } > bool check_date_with_warn(const MYSQL_TIME *ltime, uint fuzzy_date, > timestamp_type ts_type); > +bool adjust_time_range_with_warn(MYSQL_TIME *ltime, uint dec); > int test_if_number(char *str,int *res,bool allow_wildcards); > void change_byte(uchar *,uint,char,char); > bool init_read_record(READ_RECORD *info, THD *thd, TABLE *reg_form, This is 5.3, right? Take care when merging to 5.5, there's no mysql_priv.h there, only sql_priv.h and this declaration should not end up there, but in sql_time.h Regards, Sergei

2 1

Re: [Maria-developers] Rev 4019: MDEV-5505: Assertion `! is_set()' fails on PREPARE SELECT with out of range in GROUP BY
by Sergei Golubchik 26 Jan '14

26 Jan '14

Hi, Sanja! On Jan 23, sanja(a)askmonty.org wrote: > === modified file 'sql/sql_select.cc' > --- a/sql/sql_select.cc 2014-01-21 13:27:36 +0000 > +++ b/sql/sql_select.cc 2014-01-23 12:50:54 +0000 > @@ -20463,7 +20463,8 @@ find_order_in_list(THD *thd, Item **ref_ > if (!order_item->fixed && > (order_item->fix_fields(thd, order->item) || > (order_item= *order->item)->check_cols(1) || > - thd->is_fatal_error)) > + thd->is_fatal_error || > + thd->is_error())) > return TRUE; /* Wrong field. */ Why not simply > - thd->is_fatal_error)) > + thd->is_error())) can there be a fatal error that is not an error? :) Regards, Sergei

1 0