- developers - lists.mariadb.org

[Maria-developers] New problem with GTID patch
by Pavel Ivanov 28 Mar '13

28 Mar '13

Kristian, Unfortunately with your recent commit (revision 3546) test rpl.rpl_gtid_startpos doesn't work when GTID patch is applied on top of 10.0.1 tarball. It works okay in 10.0-mdev26 though, so I'm not sure if you'll want to look at the problem now. In particular the problematic addition is if (!is_relay_log && read_state_from_file()) DBUG_RETURN(1); to function MYSQL_BIN_LOG::open(). Without it test works. With it test breaks in the section "Test that master gives error when slave asks for empty gtid pos and binlog files have been purged". The problem is when get_gtid_list_event() is called from gtid_find_binlog_file() it returns event with count == 0. It causes contains_all_slave_gtid() to return true and master doesn't send error to slave as expected... I didn't look in any further details because I'm not familiar with everything that should happen here that much. If you want me to look at something else to better understand the problem let me know. Pavel

2 3

[Maria-developers] (no subject)
by Sergei Petrunia 28 Mar '13

28 Mar '13

Hello Igor, I was reviewing histogram code. Not much feedback so far, but I thought I would let you know: == Code questions == Is middle_point_pos() a good functio nname? It was not apparent to me what it meant. For me, "middle point" is a point in the middle of a range, that is, a point equidistant from both ends. Maybe, "position_in_range" will be better? == Histogram storage questions == * What does hist_size column mean? I suppose, it is number of columns in the histogram? * Do we want to support only one kind of histogram? If not, maybe we should provision space for histogram type? * The histogram column is VARBINARY(255). Why set a hard limit of 255 bytes? Maybe, use a BLOB from the start? == A possible bug == I have a column with lots of NULLs: MariaDB [test]> select nulls_ratio from mysql.column_stats where table_name='one_k' and column_name='tnulls'; +-------------+ | nulls_ratio | +-------------+ | 0.9000 | +-------------+ 1 row in set (0.00 sec) The following query crashes in maria-10.0-mwl253 tree. AFAIU, Timour has fixed the crash in 10.0-mdev83 tree. With that tree, I get: MariaDB [test]> explain extended select * from one_k where tnulls is not null; +------+-------------+-------+------+---------------+------+---------+------+------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +------+-------------+-------+------+---------------+------+---------+------+------+----------+-------------+ | 1 | SIMPLE | one_k | ALL | NULL | NULL | NULL | NULL | 969 | 100.00 | Using where | +------+-------------+-------+------+---------------+------+---------+------+------+----------+-------------+ 1 row in set, 1 warning (0.00 sec) Note that filtered=100%. It should be 10%. On Mon, Mar 25, 2013 at 11:48:30PM -0700, Igor Babaev wrote: > At file:///home/igor/maria/maria-10.0-mwl253/ > > ------------------------------------------------------------ > revno: 3502 > revision-id: igor(a)askmonty.org-20130326064829-3x0g8p1g7nbptusd > parent: igor(a)askmonty.org-20130311144424-cwqe1m70in3bora0 > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-10.0-mwl253 > timestamp: Mon 2013-03-25 23:48:29 -0700 > message: > Added histogams for table columns. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

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