- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] Rev 3965: MDEV-5403 - Reduce usage of LOCK_open: tc_count in lp:maria/10.0
by Kristian Nielsen 24 Jan '14

24 Jan '14

Sergey Vojtovich <svoj(a)mariadb.org> writes: > +#ifdef __cplusplus > +template <typename T, int S> class Atomic_type_triat; > + > + > +template <typename T> class Atomic_type_triat<T, 4> > +template <typename T> class Atomic_type_triat<T, 8> > +template <typename T, typename S= Atomic_type_triat<T, sizeof(T)> > class Atomic > + T operator++() { return add(1) + 1; } [lots and lots of more template code snipped] I am vetoing this. We really, _really_ do not want to package up the atomic stuff in even more abstractions and API layers than we already have. Atomics and lock-free stuff is in itself plenty complicated. It is crucial that one can at least see easily in the code what is going on, without also having to spend effort to understand multiple layers of wrapping. As far as I can see, the only thing the templates do is hide stuff (like the data type used and the wrapping in locks on platforms without atomic support?), while what we need is to make those details clear to people reading the code, not to hide them! - Kristian.

3 5

[Maria-developers] benchmarking next steps
by Axel Schwenke 23 Jan '14

23 Jan '14

Hi, for those of you who didn't attend the Barcelona meeting last week, here are the plans for next steps in benchmarking: 1. top priority is automatic running of DBT3 for each new release of MariaDB-10.0 and MySQL-5.6. Probably also for MariaDB-5.5. I'll send out another mail to pinpoint DBT3 conditions (i.e. which table statistics to use etc.) 2. multithreaded replication slave is now in a condition that it can and should be benchmarked 3. the problem pointed out by Yoshinori in http://yoshinorimatsunobu.blogspot.de/2013/12/single-thread-performance-reg… must be checked for MariaDB. Monty announced that he will commit a patch this week that should help with that problem. 4. for the NUMA scalability problem, Kristian will try to find the definitive reason with profiling tools. Besides that ad-hoc testing of new patches from Svoj continues as before. 5. Galera benchmarking will be done by the Galera team for now. XL

5 8

[Maria-developers] MariaDB 10.1 tree
by Sergei Petrunia 22 Jan '14

22 Jan '14

Hi, Unless there are any objections, I am going to create a 10.1 tree on Launchpad. It will be based on current 10.0. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 3

[Maria-developers] packaging
by Leif Walsh 21 Jan '14

21 Jan '14

Hi all, How do you make debian and rpm packages for mariadb? Which are the "blessed" config files and how is the process automated (and how might I run it manually)? -- Cheers, Leif

2 2

Re: [Maria-developers] MDEV-5419 no audit events for warnings converted to errors in the strict mode
by Sergei Golubchik 21 Jan '14

21 Jan '14

Hi, Holyfoot! On Dec 15, holyfoot(a)askmonty.org wrote: > revno: 4005 > revision-id: holyfoot(a)askmonty.org-20131215112825-1a5p7fa6mwdoin26 > parent: sergii(a)pisem.net-20131213120038-hjea4r5zp7sjuq8l > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-5419 > timestamp: Sun 2013-12-15 15:28:25 +0400 > message: > MDEV-5419 no audit events for warnings converted to errors in the strict mode. > Plugins get error notifications only when my_message_sql() is called. > But errors are launched with THD::raise_condition() calls in other > places. These are push_warning(), implementations of SIGNAL and > RESIGNAL commands. > So it makes sence to notify plugins there in THD::raise_condition(). Looks ok. Please add test cases for MDEV-5419 and for MDEV-4846. Then ok to push. Regards, Sergei

1 0

Re: [Maria-developers] MDEV-5364 mysql_upgrade should be more verbose
by Sergei Golubchik 21 Jan '14

21 Jan '14

Hi, Holyfoot! On Dec 15, holyfoot(a)askmonty.org wrote: > At file:///home/hf/wmar/mdev-5364/ > > ------------------------------------------------------------ > revno: 4005 > revision-id: holyfoot(a)askmonty.org-20131215104419-ks2enrs2tds0z4ti > parent: sergii(a)pisem.net-20131213120038-hjea4r5zp7sjuq8l > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-5364 > timestamp: Sun 2013-12-15 14:44:19 +0400 > message: > MDEV-5364 mysql_upgrade should be more verbose. > If the check_version_match() fails during the mysql_upgrade > execution, it doesn't print the 'mysql' output. > So the printing of the output added to the check_version_match() > and also to the get_upgrade_info_file_name() functions. Looks ok, but I'd prefer to see a test case too. Can you please add it? Ok to push with a test case. Regards, Sergei

1 0

[Maria-developers] MariaDB plugin interface and embedded library compatibility
by Honza Horak 21 Jan '14

21 Jan '14

Hi guys, I'm not able to find any information about compatibility assurance of server side -- i.e plugin interface and libmysqld.so library. I expect both should have stable API at least for one minor version across bugfix releases, but I don't believe that libmysqld.so is able to preserve ABI compatibility, since the set of exported symbols there is really huge. Can you, please, provide some simple statement (ideally as an article) what is your best afford and if we can expect API/ABI of plugin/libmysqld.so interfaces? Thanks and regards, Honza

3 3

Re: [Maria-developers] [Commits] Rev 3963: MDEV-5426: Assertion `toku_ft_needed_unlocked(src_h)' failed (errno=11) ... in file:///home/psergey/chroot/saucy-x64/home/psergey/dev2/10.0/
by Sergei Petrunia 21 Jan '14

21 Jan '14

Hi Jan, On Tue, Jan 21, 2014 at 12:18:13PM +0200, Jan Lindström wrote: > Hi, > > While the original problem is tokudb related and below fix does > nicely address it and I'm sure that you did run regression testing, > my question is does below change have any affect on other storage > engines ? Why not add test case that is run all/most of the > supported storage engines ? The problem is that I am not aware of any location where I could add a test and then it would be run for every available storage engine. The effect of the change is that now EXPLAIN INSERT ... SELECT does not make a handler->start_bulk_insert() call that's not paired with a end_bulk_insert() call. > > R: Jan > > >At file:///home/psergey/chroot/saucy-x64/home/psergey/dev2/10.0/ > > > >------------------------------------------------------------ > >revno: 3963 > >revision-id: psergey(a)askmonty.org-20140121100256-pwiacbt684azw6kj > >parent: elenst(a)opensuse.home-20131228163657-kk32bmtqogy61mwm > >committer: Sergey Petrunya <psergey(a)askmonty.org> > >branch nick: 10.0 > >timestamp: Tue 2014-01-21 14:02:56 +0400 > >message: > > MDEV-5426: Assertion `toku_ft_needed_unlocked(src_h)' failed (errno=11) ... > > - the problem was caused by EXPLAIN INSERT SELECT. For that statement, > > the code would call select_insert::prepare2(), which would call > > handler->ha_start_bulk_insert(). The corresponding handler->end_bulk_insert() > > call is made from select_insert::send_eof or select_insert::abort_result_set > > which are never called for EXPLAIN INSERT SELECT. > > - Fixed by re-using approach of mysql-5.6: don't call ha_start_bulk_insert() if > > we are in EXPLAIN. > >=== modified file 'sql/sql_insert.cc' > >--- a/sql/sql_insert.cc 2013-12-16 12:02:21 +0000 > >+++ b/sql/sql_insert.cc 2014-01-21 10:02:56 +0000 > >@@ -3555,7 +3555,8 @@ int select_insert::prepare2(void) > > { > > DBUG_ENTER("select_insert::prepare2"); > > if (thd->lex->current_select->options & OPTION_BUFFER_RESULT && > >- thd->locked_tables_mode <= LTM_LOCK_TABLES) > >+ thd->locked_tables_mode <= LTM_LOCK_TABLES && > >+ !thd->lex->describe) > > table->file->ha_start_bulk_insert((ha_rows) 0); > > DBUG_RETURN(0); > > } > > > >=== added file 'storage/tokudb/mysql-test/tokudb_mariadb/r/mdev5426.result' > >--- a/storage/tokudb/mysql-test/tokudb_mariadb/r/mdev5426.result 1970-01-01 00:00:00 +0000 > >+++ b/storage/tokudb/mysql-test/tokudb_mariadb/r/mdev5426.result 2014-01-21 10:02:56 +0000 > >@@ -0,0 +1,6 @@ > >+CREATE TABLE t1 (i INT) ENGINE=TokuDB; > >+EXPLAIN INSERT INTO t1 SELECT * FROM t1; > >+id select_type table type possible_keys key key_len ref rows Extra > >+1 SIMPLE t1 ALL NULL NULL NULL NULL 1 Using temporary > >+INSERT INTO t1 SELECT * FROM t1; > >+DROP TABLE t1; > > > >=== added file 'storage/tokudb/mysql-test/tokudb_mariadb/t/mdev5426.test' > >--- a/storage/tokudb/mysql-test/tokudb_mariadb/t/mdev5426.test 1970-01-01 00:00:00 +0000 > >+++ b/storage/tokudb/mysql-test/tokudb_mariadb/t/mdev5426.test 2014-01-21 10:02:56 +0000 > >@@ -0,0 +1,10 @@ > >+ > >+CREATE TABLE t1 (i INT) ENGINE=TokuDB; > >+EXPLAIN INSERT INTO t1 SELECT * FROM t1; > >+ > >+--connect con1,localhost,root,,test > >+INSERT INTO t1 SELECT * FROM t1; > >+ > >+--connection default > >+--disconnect con1 > >+DROP TABLE t1; > > -- BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] New message from Yoshinori Matsunobu
by Kristian Nielsen 21 Jan '14

21 Jan '14

"Facebook" <notification+xxx(a)facebookmail.com> writes: > I read your latest blog post about profile-guided optisation, which is really interesting. > > I have one question.. What perf options/arguments did you use to get INST_RETIRED.ANY and ICACHE.MISSES ? perf stat -e cache-misses? I'm not sure what options give these numbers.. perf record -e r03c -e r1c2 -e rc0 -e r280 -c 250000 sql/mysqld ... INST_RETIRED.ANY is -e rc0. ICACHE.MISSES is r280. Note that except for a few, the performance counters are processer specific. The full list of available counters is found in "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2". Eg. the ones for Sandy Bridge are found in section 19.4: http://www.intel.com/content/www/us/en/processors/architectures-software-de… (For example, ICACHE.MISSES is umask=0x02 and eventnum=0x80, hence r280.) - Kristian.

1 0

Re: [Maria-developers] [Commits] Rev 3964: MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg in file:///home/psergey/dev2/10.0-fix1/
by Kristian Nielsen 20 Jan '14

20 Jan '14

Sergey Petrunya <psergey(a)askmonty.org> writes: > ------------------------------------------------------------ > revno: 3964 > revision-id: psergey(a)askmonty.org-20140120123657-g1z4g11xmsdiw2dc > committer: Sergey Petrunya <psergey(a)askmonty.org> > message: > MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg > Undo the previous band-aid fix in psergey(a)askmonty.org-20130802141209-4dqfvx2db8acxwbl. > Kristian has made a proper fix, which uses a different approach. Thanks! - Kristian.

1 0