- developers - lists.mariadb.org

Re: [Maria-developers] Bugs in GTID implementation
by Kristian Nielsen 27 Mar '13

27 Mar '13

Pavel Ivanov <pivanof(a)google.com> writes: > way to fix them. Also if you can please look at the attached patch > containing fixes to all tests after GTID addition. There are some > questionable changes in there, so I would appreciate if you could > evaluate its correctness and consider including it into MariaDB tree. Right, so now I finished going through the whole testsuite, making all necessary adjustments to .result files (and a bit to the test cases). This is a _huge_ patch, 70k lines :-( This is due to the new GTID events, every SHOW BINLOG EVENTS and mysqldump output needs updating. I did briefly consider instead trying to filter the output to make it identical to the old one, to avoid the huge .result file changes, but I'm not really sure that is any better in the long run... So, I did this in my 10.0-mdev26 tree, which is based on 10.0-base. I noticed at least two things from your patch that are not part of this: - The --let $keep_gtid_events= 1 statements. I am not sure how this $keep_gtid_events came into the 10.0 tree. It is part of the MySQL 5.6 GTID implementation, which we do not want to merge. I would suggest you instead just remove it from show_events.inc. - There were some new testcases in mysql-test/suite/perfschema in your patch that are not in my tree. They update some digests, I did not investigate what those are about, but I will handle when I merge to 10.0 of course. Thanks for your efforts on preparing the initial patch. It was quite a nice help as a starting point, though I did do some parts of it different due to style or correctness issues. I'm likely to have missed a couple cases of course, but at least this should be a starting point, just let me know if you experience more failures. I do see a non-repatable failure in main.plugin and a DBUG crash which is also in other maria trees, I'll look at those next. The fix is pushed to lp:~maria-captains/maria/10.0-mdev26 as usual. - Kristian.

2 3

[Maria-developers] MariaDB 10 galera?
by Jan Kirchhoff 26 Mar '13

26 Mar '13

Hi, we have been playing around with 5.5.28-galera and went into more serious testing with 5.5.29-galera. We are evaluating to move from a traditional mariadb 5.2 master-slave setup to a 5 or 7 node galera cluster for our production database. I do have a good feeling so far and good experiences in our tests, but as I won't be making any major upgrades any more once we really started testing all of our processes on the galera cluster, I'd like to ask if there is any timeline for a mariadb-10.0-galera release? I couldn't find any information on the mariadb-website regarding further plans for mariadb-galera. Is there any technical reason that no binaries of mariadb-10-galera are available? Thanks Jan

2 1

Re: [Maria-developers] Bugs in GTID implementation
by Kristian Nielsen 26 Mar '13

26 Mar '13

Pavel Ivanov <pivanof(a)google.com> writes: > fixes. Meanwhile I've found one more bug in your code. In > Gtid_log_event::do_apply_event() you assume that mysql_parse() always > succeeds, you don't check thd->is_error() and always return 0. I don't Ah, right, I see. Can you test the appended patch if it fixes the problem? I tried to copy the error handling to be identical to what Query_log_event::do_apply_event("BEGIN") does. - Kristian.

2 3

Re: [Maria-developers] [Commits] Rev 3642: MDEV-4292 fix
by Sergei Golubchik 26 Mar '13

26 Mar '13

Hi, Sanja! On Mar 26, sanja(a)askmonty.org wrote: > revno: 3642 > revision-id: sanja(a)askmonty.org-20130326110746-2y3duai4mpflbq3s > parent: holyfoot(a)askmonty.org-20130322133227-szqis3jzf5izvomq > committer: sanja(a)askmonty.org > branch nick: work-maria-5.3-MDEV-4292 > timestamp: Tue 2013-03-26 13:07:46 +0200 > message: > MDEV-4292 fix. > > Fixed printing column_get finction. Is that a complete new fix? Or it's on top of the old one? Looks like new, but your words "post-review patch" confused me. Anyway, if it's a new patch - ok to push! Regards, Sergei

1 0

[Maria-developers] I would like to run a buildbot
by Dan Demeter 26 Mar '13

26 Mar '13

Hi everyone, I have 2 hardware nodes and I would be really happy to run 2 build bots, on some VMs. :) Kind regards, Dan

2 1

Re: [Maria-developers] Rev 3701: Fixed bug mdev-4311
by Sergei Golubchik 25 Mar '13

25 Mar '13

Hi, Igor! On Mar 22, Igor Babaev wrote: > At file:///home/igor/maria/maria-5.5-bug4311/ > > ------------------------------------------------------------ > revno: 3701 > revision-id: igor(a)askmonty.org-20130322224651-r2tpn9in5i1ifv7a > parent: sergii(a)pisem.net-20130317104125-yyp99euwpir5ueho > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.5-bug4311 > timestamp: Fri 2013-03-22 15:46:51 -0700 > message: > Fixed bug mdev-4311 (bug #68749). > This bug was introduced by the patch for WL#3220. > If the memory allocated for the tree to store unique elements > to be counted is not big enough to include all of them then > an external file is used to store the elements. > The unique elements are guaranteed not to be nulls. So, when > reading them from the file we don't have to care about the null > flags of the read values. However, we should remove the flag > at the very beginning of the process. If we don't do it and > if the last value written into the record buffer for the field > whose distinct values needs to be counted happens to be null, > then all values read from the file are considered to be nulls > and are not counted in. > The fix does not remove a possible null flag for the read values. > Rather it just counts the values in the same way it was done > before WL #3220. > === modified file 'sql/item_sum.cc' > --- a/sql/item_sum.cc 2013-02-28 17:42:49 +0000 > +++ b/sql/item_sum.cc 2013-03-22 22:46:51 +0000 > @@ -1460,6 +1460,12 @@ > > bool Aggregator_distinct::unique_walk_function(void *element) > { > + if (item_sum->sum_func() == Item_sum::COUNT_DISTINCT_FUNC) > + { > + Item_sum_count *sum= (Item_sum_count *)item_sum; > + sum->count++; > + return 0; > + } > memcpy(table->field[0]->ptr, element, tree_key_length); > item_sum->add(); > return 0; I'm not sure I like it. You've added a special check for COUNT_DISTINCT_FUNC just before the call of item_sum->add() which is virtual, and Item_sum_count has its own implementation of it. Logically, if there's a virtual method, the check should be in there, not in the caller. And what about SUM(DISTINCT ...) ? Perhaps it's better to mark the item not null, as you've explained in the changeset comment? Regards, Sergei

3 4

Re: [Maria-developers] Rev 3639: MDEV-4292 fix
by Sergei Golubchik 25 Mar '13

25 Mar '13

Hi, Sanja! On Mar 19, sanja(a)askmonty.org wrote: > At file:///home/bell/maria/bzr/work-maria-5.3-MDEV-4292/ > > ------------------------------------------------------------ > revno: 3639 > revision-id: sanja(a)askmonty.org-20130319105139-bxfigoel9pdbgwsn > parent: sergii(a)pisem.net-20130318074424-frdzldas283cvx1w > committer: sanja(a)askmonty.org > branch nick: work-maria-5.3-MDEV-4292 > timestamp: Tue 2013-03-19 12:51:39 +0200 > message: > MDEV-4292 fix. > > Fixed printing column_get finction. > > === modified file 'sql/item_func.cc' > --- a/sql/item_func.cc 2013-03-18 07:44:24 +0000 > +++ b/sql/item_func.cc 2013-03-19 10:51:39 +0000 > @@ -965,7 +965,11 @@ my_decimal *Item_func_numhybrid::val_dec > > void Item_func_signed::print(String *str, enum_query_type query_type) > { > - str->append(STRING_WITH_LEN("cast(")); > + if (args[0]->type() == FUNC_ITEM && > + ((Item_func *) args[0])->functype() == DYNCOL_GET_FUNC) > + str->append(STRING_WITH_LEN("column_get(")); > + else > + str->append(STRING_WITH_LEN("cast(")); > args[0]->print(str, query_type); > str->append(STRING_WITH_LEN(" as signed)")); So, as I said on irc, I don't quite like it. An Item should be independent from its arguments are should not change its name depending on the arguments. I've considered other approaches, like storing item_cast in the Item_dyncol_get or inheriting Item_dyncol_get from cast. But they all complicate the code notably. So, an easy fix that wouldn't contaminate item_cast, could be void Item_dyncol_get::print(String *str, enum_query_type query_type) { DBUG_ASSERT(strncmp(str->ptr() - 5, "cast(", 5) == 0); // see create_func_dyncol_get str->length(str->length() - 5); // removing "cast(" str->append(STRING_WITH_LEN("column_get(")); args[0]->print(str, query_type); str->append(','); args[1]->print(str, query_type); // let the parent cast item add " as <type>)" } Regards, Sergei

1 0

[Maria-developers] Aria/MyISAM and MySQL 5.6.x Compressed Table Compatibility
by Gordan Bobic 22 Mar '13

22 Mar '13

I'm having an issue with MariaDB 10.0.0. I have a bunch of archived compressed MyISAM tables from MySQL 5.6. I can move these around on MySQL 5.6 machines, but when I put them on MariaDB 10.0.0 it fails to recognize them. Has this been fixed in 10.0.1? If not, will it be fixed in 10.0.2? Gordan

2 1

[Maria-developers] Benchmark of connect performance
by Axel Schwenke 22 Mar '13

22 Mar '13

Hi, in the light of http://yoshinorimatsunobu.blogspot.fi/2012/12/non-persistent-connection-per… I did a similar benchmark. I used sysbench-0.4.12 for this with this command line $SYSBENCH --test=oltp --oltp-table-size=1000 --oltp-dist-type=uniform --num-threads=$thread --oltp-read-only=on --oltp-test-mode=simple --oltp-skip-trx --oltp-reconnect-mode=query --oltp-connect-delay=0 --db-ps-mode=disable --mysql-table-engine=InnoDB --mysql-engine-trx=no --mysql-socket=$SOCKET --max-time=60 --max-requests=0 --mysql-user=sysbench --mysql-password=sysbench --percentile=95 run This generates a workload of connect select .. where pk=const disconnect I varied the following: - number of concurrent threads - malloc library: glibc vs. tcmalloc - privileges given to sysbench@localhost * none (--skip-grant-tables) * global = ALL on *.* * db = ALL on sbtest.* * table = ALL on sbtest.sbtest I used the new 64 core machine for this. Everything was compiled locally with the REL_WITH_DEBINFO options. There is a rather huge dependence on the memory allocator. The results don't match Yoshis otherwise. See yourself. XL

3 6

[Maria-developers] Query Stuck in "closing table" State
by Gordan Bobic 20 Mar '13

20 Mar '13

I have a situation with MariaDB 10.0.0 where an INSERT INTO ... SELECT query that takes 3 seconds to run ends up stuck in the closing tables state for 15+ minutes while burning 100% of CPU. I have seen bug reports dating back 5 years that sound very similar but none of them are listed as resolved. Is there a way to debug/troubleshoot this further? The problem is quite intermittent. My data is in a state of constant flux so finding an exact reproducible test case based on data lone isn't likely to be viable. Is there a reasonable way to capture more detailed debug information than what is available from "show full processlist"? Gordan

3 7