- developers - lists.mariadb.org

[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

[Maria-developers] Top voted features for MariaDB 10.1
by Rasmus Johansson 19 Jan '14

19 Jan '14

Hi, Yesterday Daniel Bartholomew published a blog post about voting for features in MariaDB 10.1, https://blog.mariadb.org/what-do-you-want-to-see-in-mariadb-10-1/ . To make it easier to follow which the most wanted (most votes) features are I pulled together a list in JIRA for anyone interested. It can be found here https://mariadb.atlassian.net/secure/Dashboard.jspa?selectPageId=11500 . The page doesn't require login, but if you want to vote you need to log in. BR, Rasmus -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

2 1

[Maria-developers] problem with the linux thread pool in mariadb 5.5
by Rich Prohaska 16 Jan '14

16 Jan '14

we have a customer that has observed problems related to the interaction of the thread pools in mariadb 5.5.30 and tokudb 7.1.0. the problem is that connections that stuck for 100's of seconds in the Killed state when a big tokudb transaction commit is in progress. the customer claims that this problem was resolved by turning the thread pool OFF. have there been any fixes to the thread pool implementation post the 5.5.30 release? here is some information that may be useful. the processlist showed 2838 client connections of which: 851 Killed 483 Sleep 1467 Connect 1 show processlist 1 processing a commit on a big delete from a tokudb table 35 blocked on a row lock held by the big delete the Killed connections look like: 84847752 sfi_mysql 10.0.0.60:1814 sfi Killed 93 NULL 0.000 with the connection address and time slightly different a gdb snapshot of the system at the time of the failure: 291 total threads 130 threads waiting on fil_aio_wait 52 threads waiting on tokudb's work_on_kibbutz 16 thread tokudb deserialization thread waiting 36 mysql update thread blocked on the tokudb lock tree 1thread executing a big tokudb delete transaction 40 threads in the thread pool get_event function 1 tokudb checkpoint thread blocked waiting for the LP MO lock, which is held by the big txn commit thread that leaves 15 misc worker threads that are not doing anything interesting the gdb stacks for the thread pool threads are: Thread 78 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 71 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 70 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 69 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 68 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 62 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 57 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 52 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 51 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 49 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 45 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 44 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 43 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 42 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 41 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 39 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 37 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 36 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 35 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 33 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 32 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 31 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 26 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 24 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 22 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 21 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 20 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 19 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 18 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 17 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 16 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 13 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 12 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 11 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 8 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 7 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 5 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 4 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 3 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 2 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone thanks rich prohaska

1 0

[Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
by Honza Horak 14 Jan '14

14 Jan '14

Hi guys, I'm writing this as a maintainer of MariaDB package in Fedora and RHEL. I've got some complaints about libmysqlclient symbols versioning in Fedora and future RHEL-7: https://bugzilla.redhat.com/show_bug.cgi?id=1045013 Simply put, the issue there is that RPMs (both made by MariaDB upstream or Fedora community) uses different symbol versioning than it is used in other distributions (deb packages, binary tar balls) or by other MySQL providers (Oracle, Percona). Fedora does it because it used to be done that way before and it was not changed at a time upstream changed that, since Fedora started to handle symbols list on its own. MariaDB upstream adopted Fedora's behavior as a resolution of the bug: https://mariadb.atlassian.net/browse/MDEV-3923 As a result, we have different versioning only based on packaging format now, which seems to be a problem. So, I'd like to propose to sync this gap between "RPM-based packages" and "rest of the world" in the future Fedora/RHEL releases, which basically means I'd like to ask: In case Fedora 21 and RHEL-7 adopt non-versioned symbols in libmysqlclient, would MariaDB upstream be able to do the same in RPMs for these releases? There is also second difference between RPM and non-RPM builds, which is that only limited subset of symbols (those that are documented as API) is exported in the client library in Fedora RPMs. This is because we believe exporting all symbols is wrong thing. Regarding this issue, we'd like to keep the limited set of symbols in RPMs, so, the only change I'm proposing to change versioning of these symbols (as described above). Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome. Honza

2 6