- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 4563e13: MDEV-8156: Assertion failure in file log0crypt.cc line 220 on server restart
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Jan! On Jun 18, Jan Lindström wrote: > revision-id: 4563e1315df6333b280aa441e07d979d8c2ce9f4 > parent(s): eb2c170bb03fb7c98d3bd864bae46ddfb8c3acb5 > committer: Jan Lindström > branch nick: 10.1-encryption > timestamp: 2015-06-18 19:58:57 +0300 > message: > > MDEV-8156: Assertion failure in file log0crypt.cc line 220 on server restart > > Instead of asserting print informative error message to error log > and return failure from innodb_init causing the server to shutdown. A test case would've been nice Regards, Sergei

1 0

Re: [Maria-developers] [Commits] a5799f5: MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 18, svoj(a)mariadb.org wrote: > revision-id: a5799f5b087f79a8063cd10242527e9235f87597 > parent(s): 4c336c8ba4fbb4ac1a4fe9680c6899c6a49b6c46 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-18 18:01:56 +0400 > message: > > MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO > > Pass THD to Item_field (and all derivatives) constructors. > This reduces number of pthread_getspecific() calls from 322 to 292. ok to push Regards, Sergei

1 0

Re: [Maria-developers] changing some defaults related to replication
by Kristian Nielsen 18 Jun '15

18 Jun '15

Oleksandr Byelkin <sanja(a)montyprogram.com> writes: > Hi, Kristian! > > could you say against some or default changes listed here if they will > be done in 10.1? > > http://dev.mysql.com/doc/refman/5.6/en/server-default-changes.html binlog_checksum NONE CRC32 5.6.6 I am not sure that is a good idea. Binlog checksums are incompatible with earlier slave versions I think (though I guess we supported it all the way back to 5.3?). The implementation is rather bad, and not well tested in MariaDB I think, and could easily have bugs. --binlog-row-event-max-size 1024 8192 5.6.6 Seems like a good idea, 1024 is quite small. Shouldn't it default to something even larger than 8192? Seems safe to change. sync_master_info 0 10000 5.6.6 sync_relay_log 0 10000 5.6.6 sync_relay_log_info 0 10000 5.6.6 Seems safe enough, though I am not sure what the point of this change would be. I think that was all of the replication-related changes. I am not planning myself to change anything about this in 10.1, but I have no strong opinion for or against if someone else wants to do it. - Kristian.

1 0

Re: [Maria-developers] [Commits] 2e08ec2: MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 2e08ec24623e0b3d3db02333e16658dcfaa0535c > parent(s): b776f8d3a8afff55d5f8208da7bdfce9aa33eb39 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 13:09:22 +0400 > message: > > MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO > > Do not call handler::rebind_psi() and handler::unbind_psi() when performance > schema is compiled out. I don't particularly like it, you're just avoding an empty virtual function call, and that in a configuration (no P_S) which no our binaries use. But you can push it if you want. Regards, Sergei

2 2

Re: [Maria-developers] [Commits] 3f0b023: MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 3f0b02351a53e0fcaee8554c2c852fb3da8fe7da > parent(s): 5d03dd20a4abbfd9777b619dfd51a6927323955a > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 18:55:38 +0400 > message: > > MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO > > Initialize abs_timeout when it is about to be used. This saves one my_hrtime() > call on hot path (when we acquire MDL lock without waiting). ok > When filling I_S.PROCESSLIST use THD::start_utime/THD::utime_after_query instead > of THD::start_time. This allows us to save 2 clock_gettime() calls. see below > diff --git a/sql/sql_show.cc b/sql/sql_show.cc > index 1e4723d..fa3161a 100644 > --- a/sql/sql_show.cc > +++ b/sql/sql_show.cc > @@ -2730,7 +2730,7 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* tables, COND* cond) > TABLE *table= tables->table; > CHARSET_INFO *cs= system_charset_info; > char *user; > - my_hrtime_t unow= my_hrtime(); > + ulonglong unow= microsecond_interval_timer(); > DBUG_ENTER("fill_schema_processlist"); > > DEBUG_SYNC(thd,"fill_schema_processlist_after_unow"); > @@ -2793,9 +2793,12 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* tables, COND* cond) > table->field[4]->store(command_name[tmp->get_command()].str, > command_name[tmp->get_command()].length, cs); > /* MYSQL_TIME */ > - ulonglong start_utime= tmp->start_time * HRTIME_RESOLUTION + tmp->start_time_sec_part; > - ulonglong utime= start_utime && start_utime < unow.val > - ? unow.val - start_utime : 0; > + ulonglong utime= tmp->start_utime; > + ulonglong utime_after_query_snapshot= tmp->utime_after_query; > + if (utime < utime_after_query_snapshot) > + utime= utime_after_query_snapshot; // COM_SLEEP > + utime= utime && utime < unow ? unow - utime : 0; 1. Please add an assert here that utime<=unow. It uses microsecond_interval_timer(), which is supposed to be strictly increasing (unlike my_hrtime()). 2. You might need to update mysqld_list_processes() too. > table->field[5]->store(utime / HRTIME_RESOLUTION, TRUE); > /* STATE */ Regards, Sergei

2 1

Re: [Maria-developers] [Commits] 3d1b65b: MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Apr 28, svoj(a)mariadb.org wrote: > revision-id: 3d1b65b4923a49f9303501dd546af02982608b2b > parent(s): 8a0f3310275f7b4fa445f907140f677910e18999 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-28 15:20:48 +0400 > message: > > MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO > > Pass THD to find_all_keys() and Item_equal::Item_equal(). > In MRR use table->in_use instead of current_thd. > > This reduces number of pthread_getspecific() calls from 354 to 320. ok to push. although for find_all_keys() it doesn't make any sense, it's a big, complex, and expensive function. One current_thd doesn't change anything. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 2e08ec2: MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 2e08ec24623e0b3d3db02333e16658dcfaa0535c > parent(s): b776f8d3a8afff55d5f8208da7bdfce9aa33eb39 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 13:09:22 +0400 > message: > > MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO > > Do not call handler::rebind_psi() and handler::unbind_psi() when performance > schema is compiled out. > > Overhead change: > handler::rebind_psi 0.04% -> out of radar > handler::unbind_psi 0.03% -> out of radar > open_table 0.21% -> 0.18% > close_thread_table 0.05% -> 0.05% Really? I don't believe it. handler::rebind_psi() and handler::unbind_psi() are empty methods, not doing anything. There's only a cost a virtual function call. And you're saying that it took 15% of the open_table() execution time? Regards, Sergei

2 1

[Maria-developers] [GSoC] MXS-2: Week 2 and 3
by sriram patil 17 Jun '15

17 Jun '15

Hi All, Please find link to my first blog post of second and third week below. <http://srirampatil.tumblr.com/post/121594591925/mxs-2-week-2-and-3> MXS-2: Week 2 and 3 <http://srirampatil.tumblr.com/post/121594591925/mxs-2-week-2-and-3> Feel free to point out mistakes, if any. Also, suggestions ans/or reviews are welcome! Thanks, Sriram

2 2

[Maria-developers] GSoC Progress Report [MDEV-5199]
by Blessing Atie 16 Jun '15

16 Jun '15

Hi Sergei, colin! This past week I have studied the sequence engine to understand how it generates tables on the fly. I also looked at how table functions work in other databases. I am currently working on how to implement the simplest table function from our new plugin API(Still to be completed) and which will do exacly what the sequence engine does but this time in a function call like in <select * from udf_seq(1,10)>. Exams are fast approaching in my University. I will acceletrate work as soon as I finish my Exams which will run from 22nd May to 6th June and after which I will be available to the fullest capacity to put enough time on my Work. In the mean while for this week I plan on completing our plugin declaration structure and also look for other candidate functions that can be implemented. Regards, Blessing Atie.

2 1

[Maria-developers] Sprint 10.0: MDEV-8205 timediff returns null when comparing decimal time to time string value
by Alexander Barkov 16 Jun '15

16 Jun '15

Hi Sergei, I'm not sure what to do with this: > MariaDB [test]> select > -> timediff('2014-01-01 00:00:00' , '2014-01-01 01:00:00' ), > -> timediff(20140101000000.000 , 20140101010000.000 ), > -> timediff(20140101000000.000 , '2014-01-01 01:00:00' ), > -> datediff('2014-01-01 00:00:00' , '2014-01-02 01:00:00' ), > -> datediff(20140101000000.000 , 20140102010000.000 ), > -> datediff(20140101000000.000 , '2014-01-02 01:00:00' )\G > *************************** 1. row *************************** > timediff('2014-01-01 00:00:00' , '2014-01-01 01:00:00' ): -01:00:00 > timediff(20140101000000.000 , 20140101010000.000 ): -01:00:00.000 > timediff(20140101000000.000 , '2014-01-01 01:00:00' ): NULL > datediff('2014-01-01 00:00:00' , '2014-01-02 01:00:00' ): -1 > datediff(20140101000000.000 , 20140102010000.000 ): -1 > datediff(20140101000000.000 , '2014-01-02 01:00:00' ): -1 > 1 row in set (0.03 sec) Notice, it returns NULL in one case. The problem is in this piece of the code: > if (args[0]->get_time(&l_time1) || > args[1]->get_time(&l_time2) || > l_time1.time_type != l_time2.time_type) > return (null_value= 1); get_time() forces decimal-to-time conversion to truncate the date part and return MYSQL_TIMESTAMP_TIME. get_time() does not force string-to-time conversion to truncate the date part. It still returns the full MYSQL_TIMESTAMP_DATETIME. I'm afraid a lot of the code rely in this behavior. If we fix string-to-time conversion, mtr will start to fail in other cases. Any ideas what to do?

2 4