- developers - lists.mariadb.org

Re: [Maria-developers] [All] How are we going to handle incompatible changes in MariaDB?
by Kristian Nielsen 18 Mar '11

18 Mar '11

"Philip Stoev" <pstoev(a)askmonty.org> writes: > We should discuss how do we handle new developments in MariaDB that cause > our behavior to diverge from the one in MySQL. Since we claim to be a Yes, agree. Thank you for bringing it up! Note that this is a general MariaDB discussion, not a Monty Program specific one. So I move the thread to maria-developers@. So far, we have generally been ok at handing incompatible changes. The basic approach is to shape new features to be backwards compatible as much as possible, and to add any extra needed code to handle interoperability. For example, if an option is changed due to a feature, we should keep the old option around and emulate the bahaviour, eventually deprecating it in a future version. Another example, with replication, we check the version of the master or slave at the other end, and take care to only send what the other end understands, and likewise interpret what it sends correctly based on its version. However, this has been mostly up to the individual developer (or often reviewer), and if we can get some more structure/process to this to avoid it being forgotten, then that would be very good. > The particular situation we are facing now is the microsecond precision > patch from Serg. As part of introducing precision date and time datatypes, > he made some refactoring around the Item_* tree. > > As a result, various corner cases, e.g. invalid dates, partially valid > dates, invalid conversions between date and time, etc. are now handled > differently, with either different warnings being printed (or no warnings at > all), or with the result of the expression being different, or with a NULL > or 0000-00-00 returned. > > For example, mysql reports that DATE ( SEC_TO_TIME( 8 ) ) is equal to > "2000-00-08" whereas serg's patch returns "0000-00-00" . In other words, > MySQL chose to place the "8" literal into the days portion of the date > value, whereas Serg's patch filtered the literal somewhere along the way. > There are numerous other such examples. > > While in most cases Serg's new behavior is more intuitive and a program that > is written to conform to postgresql-level type safety will not be affected > either way, it entirely possible that a program written under mysql's > relaxed type safety rules, and with MySQL's behavior in mind, would start > behaving unexpectedly. It sounds like in this case, the changes in behaviour could be considered improvements, or even bug fixes, when seen in isolation. And the behaviour they change is not something that an application would deliberately be written to rely on. But since it is a change in behaviour, it has the potential to break applications that by accident happen to depend on such behaviour. My opinion on this is that we should do the change in a major version (eg. 5.2->5.3), but not in a minor version (eg. 5.2.5->5.2.6). And document it in release notes as an incompatible change. Basically the same way we did in MySQL (and still do, I suppose). It is ok to change behaviour in a major version, if it is necessary, and documented. I believe users anticipate such changes, and consequently are more careful about going eg. 5.1->5.5 than 5.1.x->5.1.y. We should not needlessly change things. Every behaviour change should be carefully considered. If it has the potential to seriously break major applications, we should not change it (or use deprecation, compatibility mode, etc). If the change is not necessary or useful, it should probably be left. But if the change makes sense and the new behaviour is much more reasonable, then we should be ready to make the change. We cannot afford to be stuck forever on old poor decisions. Another example is optimiser changes. In my opinion, we cannot totally avoid that improvements to the optimiser will make some corner case queries slower in some cases. The optimiser has only limited knowledge of the data and application. If, based on this knowledge, execution plan A is better than execution plan B, then we should be prepared to change (in a major version) the code to select A over B. This will invaribly cause slowdown in some cases, where the knowledge is incomplete. But it is important to be able to make improvements. But again, we need to consider each case carefully. We should not do things that are obviously stupid (eg. do not select table scan over range scan unless _really_ sure it will be better), and we should avoid breaking major applications or use patterns, even if it theoretically makes sense. So summary of my opinion: We should be very careful about incompatible changes. We should generally avoid them unless there is a very good reason for them. We should create backward compatibility where possible and where it makes sense. And if we do change behaviour, we should only do it in a major version and document it clearly in an "incompatible changes" list. And being able to continually improve the server long-term is important. > So, how we should handle this particular case, and more importantly, how do > we handle future cases like that in a stable and predictable manner? I > understand that in the early days of MySQL it would have been a no-brainer > to change everything as needed, we are by now dealing with a huge installed > base and powerful competitors, so we can not simply apply the happy hacking > approach that was used in the 1990s. Agree. No "happy hacking" approach to incompatible changes! - Kristian.

1 0

[Maria-developers] request for feedback on live schema changes patch
by Zardosht Kasheff 18 Mar '11

18 Mar '11

Hello all, In another thread, there was a discussion about what it would take to allow the storage engine to support live schema changes in mysql and mariadb. I said that I was working porting this existing feature from MySQL Cluster to MySQL 5.1.46. I would like to show the work I have done so far and solicit feedback. Attached is the diff based off of 5.1.46. Before looking at the patch, please be aware of the following things: - I am not an expert in this code. As a result, I had to use an approach of that minimizes the risk of introducing regressions. \ - My main interest is to get something safe that works and can be integrated in 5.1. As a result, kept the current mysql_alter_table functionality in place (as old_mysql_alter_table), and added MySQL Cluster's as new_mysql_alter_table. For an engine to get new_mysql_alter_table to be used, the engine must expose an alter table flag HA_GENERAL_ONLINE. - Another reason why I kept old_mysql_alter_table was that I did not want to deal with engines that implement handler::add_index and make sure that they work properly under the new API. Also, I did not want to port alter table changes related to partitioned tables. - I have run the current 5,1 mysql test suite (that is in the mysql-test directory of source tarballs), and verified that using old_mysql_alter_table and new_mysql_alter_table works fine with them. That being said, I would love to hear feedback on this patch, and would also like to understand what (if anything) can be done to get this into MariaDB 5.1. I realize that may not be possible, but if it is, I would like to try. Thanks -Zardosht

2 5

[Maria-developers] WL#182 New (by Mdcallag): Explain running statements
by worklog-noreply＠askmonty.org 13 Mar '11

13 Mar '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Explain running statements CREATION DATE..: Sun, 13 Mar 2011, 09:44 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Client-BackLog TASK ID........: 182 (http://askmonty.org/worklog/?tid=182) VERSION........: Benchmarks-3.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: I want to know the query plan for running statements -- something like "SHOW PLAN FOR <connection_id>". This requires running statements to generate a string that describes their plan in case another thread needs to examine it. For me it would be good enough to know the join order and indexes. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] URLs for worklog tasks include bin name
by MARK CALLAGHAN 13 Mar '11

13 Mar '11

When I click on http://askmonty.org/worklog/?tid=180 I end up at http://askmonty.org/worklog/WorkLog-RawIdeaBin/?tid=180. Is that last URL only valid as long as tid=180 remains in the RawIdea bin? If so, then when I share it in email or include that URL elsewhere how are people to use it when tid=180 is moved from the RawIdeaBin to another bin? -- Mark Callaghan mdcallag(a)gmail.com

1 0

[Maria-developers] User Comment -> Add Comment is bugging in MariaDB worklogs
by MARK CALLAGHAN 13 Mar '11

13 Mar '11

Go to a worklog, Scroll down, Click on "Add a new comment" This takes me back to the top of the page. This is confusing and now I must scroll down again to reach the comment text box. Add text, click on OK This takes me to another page that has a text box. The text I previously entered is lost. This is a bug. If I enter text on this page and click OK it is not lost. -- Mark Callaghan mdcallag(a)gmail.com

1 1

Re: [Maria-developers] [Commits] Rev 2935: Fixed LP bugs BUG#729067/730466. in file:///home/igor/maria/maria-5.3-bug729067/
by Oleksandr Byelkin 12 Mar '11

12 Mar '11

Hi! Ok to push. 12 марта 2011, в 10:49, Igor Babaev написал(а): > At file:///home/igor/maria/maria-5.3-bug729067/ > > ------------------------------------------------------------ > revno: 2935 > revision-id: igor(a)askmonty.org-20110312084903-b9mmi2wdgbdar3tc > parent: timour(a)askmonty.org-20110308212344-7r4ue17b3rxschlj > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.3-bug729067 > timestamp: Sat 2011-03-12 00:49:03 -0800 > message: > Fixed LP bugs BUG#729067/730466. > Do not reset the value of the item_equal field in the Item_field object > once it has been set. > === modified file 'mysql-test/r/join.result' > --- a/mysql-test/r/join.result 2011-02-28 21:29:59 +0000 > +++ b/mysql-test/r/join.result 2011-03-12 08:49:03 +0000 > @@ -1285,3 +1285,38 @@ > 1 1 1 1 1 > 1 1 1 1 1 > drop table t1,t2,t3; > +# > +# BUG#729067/730466: unexpected 'Range checked for each record' > +# for queries with OR in WHERE clause > +# > +CREATE TABLE t1 (f1 int, f2 int) ; > +INSERT INTO t1 VALUES (4,0),(5,1); > +CREATE TABLE t2 (f1 int, f2 int, KEY (f2)) ; > +INSERT INTO t2 VALUES (5,7), (8,9); > +EXPLAIN > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > +WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE t1 ALL NULL NULL NULL NULL 2 Using where > +1 SIMPLE t2 ALL f2 NULL NULL NULL 2 Using where; Using join buffer (flat, BNL join) > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > +WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > +f1 f2 f1 f2 > +5 1 5 7 > +DROP TABLE t1,t2; > +CREATE TABLE t1(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t1 VALUES (9,4), (10,9); > +CREATE TABLE t2(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t2 VALUES (9,4), (10,9); > +EXPLAIN > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > +WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > +id select_type table type possible_keys key key_len ref rows Extra > +1 PRIMARY t1 ALL PRIMARY NULL NULL NULL 2 Using where > +1 PRIMARY t2 ALL PRIMARY NULL NULL NULL 2 Using where; Using join buffer (flat, BNL join) > +2 SUBQUERY t1 index NULL PRIMARY 4 NULL 2 Using index > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > +WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > +f1 f2 f1 f2 > +9 4 10 9 > +DROP TABLE t1,t2; > > === modified file 'mysql-test/t/join.test' > --- a/mysql-test/t/join.test 2011-02-28 21:29:59 +0000 > +++ b/mysql-test/t/join.test 2011-03-12 08:49:03 +0000 > @@ -964,3 +964,36 @@ > > drop table t1,t2,t3; > > +--echo # > +--echo # BUG#729067/730466: unexpected 'Range checked for each record' > +--echo # for queries with OR in WHERE clause > +--echo # > + > +CREATE TABLE t1 (f1 int, f2 int) ; > +INSERT INTO t1 VALUES (4,0),(5,1); > + > +CREATE TABLE t2 (f1 int, f2 int, KEY (f2)) ; > +INSERT INTO t2 VALUES (5,7), (8,9); > + > +EXPLAIN > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > + WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > +SELECT * FROM t1 STRAIGHT_JOIN t2 ON t2.f1 = t1.f1 > + WHERE t1.f1<>0 OR t1.f2<>0 AND t1.f1 = t2.f2; > + > +DROP TABLE t1,t2; > + > +CREATE TABLE t1(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t1 VALUES (9,4), (10,9); > + > +CREATE TABLE t2(f1 int PRIMARY KEY, f2 int) ; > +INSERT INTO t2 VALUES (9,4), (10,9); > + > +EXPLAIN > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > + WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > +SELECT STRAIGHT_JOIN * FROM t1 JOIN t2 ON t2.f2 = t1.f1 > + WHERE t1.f1 IN (SELECT f1 FROM t1) AND t1.f1 = t2.f1 OR t1.f1 = 9; > + > +DROP TABLE t1,t2; > + > > === modified file 'sql/item_cmpfunc.cc' > --- a/sql/item_cmpfunc.cc 2011-02-06 04:57:03 +0000 > +++ b/sql/item_cmpfunc.cc 2011-03-12 08:49:03 +0000 > @@ -5723,7 +5723,8 @@ > not_null_tables_cache|= tmp_table_map; > if (item->maybe_null) > maybe_null=1; > - item->item_equal= this; > + if (!item->item_equal) > + item->item_equal= this; > } > fix_length_and_dec(); > fixed= 1; > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

Re: [Maria-developers] [Commits] Rev 2934: Fix LP BUG#719198 in file:///home/tsk/mprog/src/5.3/
by Sergey Petrunya 08 Mar '11

08 Mar '11

Hi Timour, On Tue, Mar 08, 2011 at 04:35:24PM +0200, timour(a)askmonty.org wrote: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 2934 > revision-id: timour(a)askmonty.org-20110308143512-0m7uotvxp9rmegak > parent: psergey(a)askmonty.org-20110304155430-l0ad4iag9gn5zeka > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Tue 2011-03-08 16:35:12 +0200 > message: > Fix LP BUG#719198 > > Analysis: > The assert failed because the execution code for > partial matching is designed with the assumption that > NULLs on the left side are detected as early as possible, > and a NULL result is returned before any lookups are > performed at all. > > However, in the case of an Item_cache object on the left > side, null was not detected properly, because detection > was done via Item::is_null(), which is not implemented at > all for Item_cache, and resolved to the default Item::is_null() > which always returns FALSE. > > Solution: > Use the property Item::null_value instead of is_null(), which > is properly updated for Item_cache objects as well. > > Alternatively one could implement Item_cache:is_null(), but > its not quite clear how that will interact with the cache > update methods, so the current fix seems simpler and cleaner. Ok to push. Since it is guaranteed that cache_value() have been called for the object, it's ok to use null_value instead of is_null(). Btw, out of interest I've implemented Item_cache::is_null() and t/subselect*.test ran successfully, so it seems to be ok to have. I don't insist that it is added as part of this fix, though. > === modified file 'mysql-test/r/subselect_mat.result' > --- a/mysql-test/r/subselect_mat.result 2011-01-14 10:51:30 +0000 > +++ b/mysql-test/r/subselect_mat.result 2011-03-08 14:35:12 +0000 > @@ -1371,3 +1371,41 @@ SELECT pk FROM t1 WHERE (b,c,d) IN (SELE > pk > 2 > DROP TABLE t1, t2; > +# > +# LPBUG#719198 Ordered_key::cmp_key_with_search_key(rownum_t): Assertion `!compare_pred[i]->null_value' > +# failed with subquery on both sides of NOT IN and materialization > +# > +CREATE TABLE t1 (f1a int, f1b int) ; > +INSERT IGNORE INTO t1 VALUES (1,1),(2,2); > +CREATE TABLE t2 ( f2 int); > +INSERT IGNORE INTO t2 VALUES (3),(4); > +CREATE TABLE t3 (f3a int, f3b int); > +set session optimizer_switch='materialization=on,partial_match_rowid_merge=on,partial_match_table_scan=off'; > +EXPLAIN > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1); > +id select_type table type possible_keys key key_len ref rows Extra > +1 PRIMARY t2 ALL NULL NULL NULL NULL 2 Using where > +3 SUBQUERY t1 ALL NULL NULL NULL NULL 2 > +2 SUBQUERY t3 system NULL NULL NULL NULL 0 const row not found > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1); > +f2 > +EXPLAIN > +SELECT * FROM t2 WHERE (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1); > +id select_type table type possible_keys key key_len ref rows Extra > +1 PRIMARY t2 ALL NULL NULL NULL NULL 2 Using where > +3 SUBQUERY t1 ALL NULL NULL NULL NULL 2 > +2 SUBQUERY t3 system NULL NULL NULL NULL 0 const row not found > +SELECT * FROM t2 WHERE (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1); > +f2 > +insert into t3 values (1,1),(2,2); > +EXPLAIN > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3 where f3a > 3) NOT IN (SELECT f1a FROM t1); > +id select_type table type possible_keys key key_len ref rows Extra > +1 PRIMARY t2 ALL NULL NULL NULL NULL 2 Using where > +3 SUBQUERY t1 ALL NULL NULL NULL NULL 2 > +2 SUBQUERY t3 ALL NULL NULL NULL NULL 2 Using where > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3 where f3a > 3) NOT IN (SELECT f1a FROM t1); > +f2 > +3 > +4 > +drop table t1, t2, t3; > > === modified file 'mysql-test/t/subselect_mat.test' > --- a/mysql-test/t/subselect_mat.test 2011-01-14 10:51:30 +0000 > +++ b/mysql-test/t/subselect_mat.test 2011-03-08 14:35:12 +0000 > @@ -1011,3 +1011,31 @@ SELECT pk FROM t1 WHERE (a) IN (SELECT a > SELECT pk FROM t1 WHERE (b,c,d) IN (SELECT b,c,d FROM t2 WHERE pk > 0); > DROP TABLE t1, t2; > > +--echo # > +--echo # LPBUG#719198 Ordered_key::cmp_key_with_search_key(rownum_t): Assertion `!compare_pred[i]->null_value' > +--echo # failed with subquery on both sides of NOT IN and materialization > +--echo # > + > +CREATE TABLE t1 (f1a int, f1b int) ; > +INSERT IGNORE INTO t1 VALUES (1,1),(2,2); > +CREATE TABLE t2 ( f2 int); > +INSERT IGNORE INTO t2 VALUES (3),(4); > +CREATE TABLE t3 (f3a int, f3b int); > + > +set session optimizer_switch='materialization=on,partial_match_rowid_merge=on,partial_match_table_scan=off'; > + > +EXPLAIN > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1); > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1); > + > +EXPLAIN > +SELECT * FROM t2 WHERE (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1); > +SELECT * FROM t2 WHERE (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1); > + > +insert into t3 values (1,1),(2,2); > + > +EXPLAIN > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3 where f3a > 3) NOT IN (SELECT f1a FROM t1); > +SELECT * FROM t2 WHERE (SELECT f3a FROM t3 where f3a > 3) NOT IN (SELECT f1a FROM t1); > + > +drop table t1, t2, t3; > > === modified file 'sql/item_subselect.cc' > --- a/sql/item_subselect.cc 2011-03-03 21:48:31 +0000 > +++ b/sql/item_subselect.cc 2011-03-08 14:35:12 +0000 > @@ -5069,7 +5069,7 @@ bool subselect_rowid_merge_engine::parti > for (uint i= test(non_null_key); i < keys_count; i++) > { > DBUG_ASSERT(merge_keys[i]->get_column_count() == 1); > - if (merge_keys[i]->get_search_key(0)->is_null()) > + if (merge_keys[i]->get_search_key(0)->null_value) > { > ++count_nulls_in_search_key; > bitmap_set_bit(&matching_outer_cols, merge_keys[i]->get_keyid()); > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MWL#90 combined patch for review
by Sergey Petrunya 08 Mar '11

08 Mar '11

Hi Monty, Please find attached the complete patch of MWL#90 for review. The tree with the code is on launchpad/buildbot: https://code.launchpad.net/~maria-captains/maria/5.3-subqueries-mwl90 http://buildbot.askmonty.org/buildbot/grid?branch=5.3-subqueries-mwl90 and it has no failures other than those also found in mainline 5.3. The merge from 5.3-main was about a week ago. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 5

[Maria-developers] Report from OpenSourceDays2011
by Kristian Nielsen 08 Mar '11

08 Mar '11

Hi, On Saturday, March 5, I gave a talk at the OpenSourceDays 2011 conference in Copenhagen, Denmark: http://opensourcedays.org/ My talk was titled "Latest news from the MariaDB (and MySQL) community". I put the slides from the talk up on my web server here: http://knielsen-hq.org/maria/osd2011.pdf This year the OpenSourceDays conference was reduced somewhat from what it usually is, only one day and I heard something like 400 tickes available (which were sold out rather quickly). Still, I had a good bunch of people at the talk, maybe 30 or so. There were many questions, people seemed interested, so I think it went well. I also talked to some people outside of the talk, again there seems to be a lot of interest in what is happening around MySQL generally and in MariaDB specifically. I think generally people are pleasantly surprised to learn the depth and dedication of the MariaDB effort, that we really are a major effort and a viable alternative. There was one good question at the talk about if there were reference customer statements or so to show that companies are deploying MariaDB with success at large scale; I guess this will be useful for people that want to sell the idea of using MariaDB at their job or institution or whatever. I did not have a very good answer to this, except that I knew there were some. I guess we already have this on one of the web sites, or if not it would be worth it to collect the different press releases and such as we get them, I think. The night before the conference there was a speaker's dinner, and I had a great talk with Magnus from Postgresql. I got the impression that things are also really moving in the Postgres space, and it seems to be picking up a lot of interest and development effort. I think that is great, I am starting to be hopeful that we are now seeing the open source databases really take off as a community effort, as opposed to just a project of whatever "acquirer of the year". That's it :-) - Kristian.

2 1

[Maria-developers] Pbxt loses rows
by Michael Widenius 08 Mar '11

08 Mar '11

Hi! This is a bug that has been around a long time but not yet fixed (at least not in 1.0.11 which is in the MariaDB 5.1 tree). Once in a while when running the pbxt.insert test, pbxt fails to find all rows in the table: pbxt.insert [ fail ] Test ended at 2011-02-25 16:44:03 CURRENT_TEST: pbxt.insert --- /home/my/maria-5.1-merge/mysql-test/suite/pbxt/r/insert.result 2011-02-10 22:57:21.000000000 +0200 +++ /home/my/maria-5.1-merge/mysql-test/suite/pbxt/r/insert.reject 2011-02-25 16:44:03.030856755 +0200 @@ -298,7 +298,7 @@ insert into t2 select t1.* from t1, t2 t, t3 where t1.id1 = t.id2 and t.id2 = t3.id3; select count(*) from t2; count(*) -25500 +25495 drop table t1,t2,t3; create table t1 (a int, b int); insert into t1 (a,b) values (a,b); Rerunning the test usually works It would be really good to get this fixes ASAP as it's not good if a storage engines looses rows randomly... The above happend in my latest 5.1 tree on Linux. Regards, Monty

2 2