[Maria-developers] Test failures in PBXT after merging with MySQL-5.1.41
Hi Paul, Vladimir, We are working on merging latest MySQL (5.1.41) into MariaDB. After the merge, I see some test failures in the PBXT test suite. See here: https://askmonty.org/buildbot/builders/hardy-amd64-fulltest/builds/118/steps... Or if you prefer, see here for a search for these failures in the build history database: http://askmonty.org/buildbot/reports/cross_reference#branch=5.1-merge&revision=2768&platform=hardy-amd64-fulltest&dt=&bbnum=&typ=&info=&fail_name=pbxt.&fail_variant=&fail_info_short=&fail_info_full=
From a quick look, it seems to me most/all of these are just the need to adjust result files for changes/bugfixes in MySQL. But before spending time on fixing, I though it was better to coordinate with you, to not duplicate effort.
So perhaps you already did the similar changes for the PBXT testsuite against MySQL 5.1.41? Is there maybe a newer version of PBXT that we should merge? Or alternatively, do you want me to fix the testsuite, and then send you a patch for merging into PBXT to update to 5.1.41? - Kristian.
Hi Kristian, You are welcome to make the changes to the PBXT tests. For the PBXT trunk we are still using 5.1.35 for testing, but this should not be a problem. I had a look, and the only failure that is a bit odd is: pbxt.subselect mysqltest: At line 34: query 'SELECT 1 FROM (SELECT 1) a PROCEDURE ANALYSE((SELECT 1))' failed with wrong errno 1108: 'Incorrect parameters to procedure 'ANALYSE'', instead of 1221... Looks like NALYSE((SELECT 1)) is no longer possible. I am currently updating the PBXT version in MariaDB to 1.0.09 (RC3). I will propose a merge for this shortly. Best regards, Paul On Nov 24, 2009, at 9:01 AM, Kristian Nielsen wrote:
Hi Paul, Vladimir,
We are working on merging latest MySQL (5.1.41) into MariaDB.
After the merge, I see some test failures in the PBXT test suite. See here:
https://askmonty.org/buildbot/builders/hardy-amd64-fulltest/builds/118/steps...
Or if you prefer, see here for a search for these failures in the build history database:
http://askmonty.org/buildbot/reports/cross_reference#branch=5.1- merge&revision=2768&platform=hardy-amd64- fulltest &dt = &bbnum = &typ =&info=&fail_name=pbxt.&fail_variant=&fail_info_short=&fail_info_full=
From a quick look, it seems to me most/all of these are just the need to adjust result files for changes/bugfixes in MySQL. But before spending time on fixing, I though it was better to coordinate with you, to not duplicate effort.
So perhaps you already did the similar changes for the PBXT testsuite against MySQL 5.1.41? Is there maybe a newer version of PBXT that we should merge?
Or alternatively, do you want me to fix the testsuite, and then send you a patch for merging into PBXT to update to 5.1.41?
- Kristian.
-- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
Paul McCullagh <paul.mccullagh@primebase.org> writes:
You are welcome to make the changes to the PBXT tests. For the PBXT trunk we are still using 5.1.35 for testing, but this should not be a problem.
Ok, will do, I will send you a link to the patch/commit.
I had a look, and the only failure that is a bit odd is: pbxt.subselect
mysqltest: At line 34: query 'SELECT 1 FROM (SELECT 1) a PROCEDURE ANALYSE((SELECT 1))' failed with wrong errno 1108: 'Incorrect parameters to procedure 'ANALYSE'', instead of 1221...
Looks like NALYSE((SELECT 1)) is no longer possible.
I think this is due to the fix for this bug: http://bugs.mysql.com/bug.php?id=48293 So it should be ok, I think I had the same issue for XtraDB tests.
I am currently updating the PBXT version in MariaDB to 1.0.09 (RC3). I will propose a merge for this shortly.
Ok, excellent! Thanks, - Kristian.
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
Paul McCullagh <paul.mccullagh@primebase.org> writes:
You are welcome to make the changes to the PBXT tests. For the PBXT trunk we are still using 5.1.35 for testing, but this should not be a problem.
Ok, will do, I will send you a link to the patch/commit.
Here it is: https://lists.launchpad.net/maria-developers/msg01535.html - Kristian. PS. I now get this in the mysqld.err log after server shutdown in PBXT test suite: 091124 13:09:45 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 13:09:45 [Warning] Plugin 'PBXT' will be forced to shutdown Do you know anything about what this means? Is it a problem to be fixed, or just a harmless warning caused by the test suite framework? - Kristian.
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
PS. I now get this in the mysqld.err log after server shutdown in PBXT test suite:
091124 13:09:45 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 13:09:45 [Warning] Plugin 'PBXT' will be forced to shutdown
Ok, some more details: I can repeat this by running an empty test case (mysql-test/suite/pbxt/t/kn.test): ------------------------------ cut here ------------------------------ --skip "Test shutdown problem with skipped test" ------------------------------ cut here ------------------------------ (cd mysql-test && perl mysql-test-run.pl --suite=pbxt pbxt.kn) I get this in the mysqld.1.err: CURRENT_TEST: pbxt.kn 091124 15:11:00 [Note] Plugin 'InnoDB' is disabled. 091124 15:11:00 [Note] PrimeBase XT (PBXT) Engine 1.0.08d RC loaded... 091124 15:11:00 [Note] Paul McCullagh, PrimeBase Technologies GmbH, http://www.primebase.org 091124 15:11:00 [Note] Event Scheduler: Loaded 0 events 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/sql/mysqld: ready for connections. Version: '5.1.41-mariadb-beta-valgrind-max-debug-log' socket: '/home/knielsen/devel/maria/my/merge-5.1.41/mysql-test/var/tmp/mysqld.1.sock' port: 13000 Source distribution 091124 15:11:00 [Note] Got signal 15 to shutdown mysqld 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/sql/mysqld: Normal shutdown 091124 15:11:00 [Note] Event Scheduler: Purging the queue. 0 events 091124 15:11:00 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 15:11:00 [Warning] Plugin 'PBXT' will be forced to shutdown 091124 15:11:00 [Note] PrimeBase XT Engine shutdown... 091124 15:11:00 [Note] Debug sync points hit: 50 091124 15:11:00 [Note] Debug sync points executed: 0 091124 15:11:00 [Note] Debug sync points max active per thread: 0 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/sql/mysqld: Shutdown complete This is from this tree on Launchpad containing the merge with MySQL 5.1.41: lp:~maria-captains/maria/5.1-merge The problem is that the ref_count of PBXT is 2 at shutdown time. Maybe this is another problem with the way that PBXT has to do init in a separate thread, I see you already had to solve some other possibly related problems. Any ideas? It may be that this is something introduced in the merge with MySQL 5.1.41, not 100% sure though as this particular warning was not detected before in our Buildbot tests... - Kristian.
Hi Kristian, I have seen this warning occasionally with other versions of MySQL. Since it also happens with MyISAM and sometimes other engines, I had not given it much thought before. However, it would be good to track down exactly where this reference is being held. To repeat the error, do I just create an empty file called kn.test, and run: mysql-test-run.pl --suite=pbxt pbxt.kn Thanks, Paul On Nov 24, 2009, at 1:21 PM, Kristian Nielsen wrote:
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
PS. I now get this in the mysqld.err log after server shutdown in PBXT test suite:
091124 13:09:45 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 13:09:45 [Warning] Plugin 'PBXT' will be forced to shutdown
Ok, some more details:
I can repeat this by running an empty test case (mysql-test/suite/pbxt/t/kn.test):
------------------------------ cut here ------------------------------ --skip "Test shutdown problem with skipped test" ------------------------------ cut here ------------------------------
(cd mysql-test && perl mysql-test-run.pl --suite=pbxt pbxt.kn)
I get this in the mysqld.1.err:
CURRENT_TEST: pbxt.kn 091124 15:11:00 [Note] Plugin 'InnoDB' is disabled. 091124 15:11:00 [Note] PrimeBase XT (PBXT) Engine 1.0.08d RC loaded... 091124 15:11:00 [Note] Paul McCullagh, PrimeBase Technologies GmbH, http://www.primebase.org 091124 15:11:00 [Note] Event Scheduler: Loaded 0 events 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/ sql/mysqld: ready for connections. Version: '5.1.41-mariadb-beta-valgrind-max-debug-log' socket: '/ home/knielsen/devel/maria/my/merge-5.1.41/mysql-test/var/tmp/mysqld. 1.sock' port: 13000 Source distribution 091124 15:11:00 [Note] Got signal 15 to shutdown mysqld 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/ sql/mysqld: Normal shutdown
091124 15:11:00 [Note] Event Scheduler: Purging the queue. 0 events 091124 15:11:00 [Warning] Plugin 'MyISAM' will be forced to shutdown 091124 15:11:00 [Warning] Plugin 'PBXT' will be forced to shutdown 091124 15:11:00 [Note] PrimeBase XT Engine shutdown... 091124 15:11:00 [Note] Debug sync points hit: 50 091124 15:11:00 [Note] Debug sync points executed: 0 091124 15:11:00 [Note] Debug sync points max active per thread: 0 091124 15:11:00 [Note] /home/knielsen/devel/maria/my/merge-5.1.41/ sql/mysqld: Shutdown complete
This is from this tree on Launchpad containing the merge with MySQL 5.1.41:
lp:~maria-captains/maria/5.1-merge
The problem is that the ref_count of PBXT is 2 at shutdown time.
Maybe this is another problem with the way that PBXT has to do init in a separate thread, I see you already had to solve some other possibly related problems. Any ideas? It may be that this is something introduced in the merge with MySQL 5.1.41, not 100% sure though as this particular warning was not detected before in our Buildbot tests...
- Kristian.
-- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
Paul McCullagh <paul.mccullagh@primebase.org> writes:
I have seen this warning occasionally with other versions of MySQL.
Since it also happens with MyISAM and sometimes other engines, I had not given it much thought before.
As I understand it, the reason for the message about MyISAM is that PBXT is keeping references (directly or indirectly) to MyISAM.
However, it would be good to track down exactly where this reference is being held.
To repeat the error, do I just create an empty file called kn.test, and run:
mysql-test-run.pl --suite=pbxt pbxt.kn
No, the file should contain a single line as follows: ------------------------------ cut here ------------------------------ --skip "Test shutdown problem with skipped test" ------------------------------ cut here ------------------------------ (eg. this is a test that is always skipped). At least for me this allowed to repeat reliably. - Kristian.
OK, thanks! This has been reported as bug #489088 (https://bugs.launchpad.net/pbxt/+bug/489088 ) We will have a look... On Nov 26, 2009, at 7:45 PM, Kristian Nielsen wrote:
Paul McCullagh <paul.mccullagh@primebase.org> writes:
I have seen this warning occasionally with other versions of MySQL.
Since it also happens with MyISAM and sometimes other engines, I had not given it much thought before.
As I understand it, the reason for the message about MyISAM is that PBXT is keeping references (directly or indirectly) to MyISAM.
However, it would be good to track down exactly where this reference is being held.
To repeat the error, do I just create an empty file called kn.test, and run:
mysql-test-run.pl --suite=pbxt pbxt.kn
No, the file should contain a single line as follows:
------------------------------ cut here ------------------------------ --skip "Test shutdown problem with skipped test" ------------------------------ cut here ------------------------------
(eg. this is a test that is always skipped). At least for me this allowed to repeat reliably.
- Kristian.
-- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
Hi Kristian, apart from the error mentioned by Paul it looks like the rest of test results just need update. SHOW GRANTS needs resultset ordering. BR, Vlad Kristian Nielsen wrote:
Hi Paul, Vladimir,
We are working on merging latest MySQL (5.1.41) into MariaDB.
After the merge, I see some test failures in the PBXT test suite. See here:
https://askmonty.org/buildbot/builders/hardy-amd64-fulltest/builds/118/steps...
Or if you prefer, see here for a search for these failures in the build history database:
From a quick look, it seems to me most/all of these are just the need to adjust result files for changes/bugfixes in MySQL. But before spending time on fixing, I though it was better to coordinate with you, to not duplicate effort.
So perhaps you already did the similar changes for the PBXT testsuite against MySQL 5.1.41? Is there maybe a newer version of PBXT that we should merge?
Or alternatively, do you want me to fix the testsuite, and then send you a patch for merging into PBXT to update to 5.1.41?
- Kristian.
-- -- Best Regards, Vladimir
Kristian Nielsen <knielsen@knielsen-hq.org> writes:
We are working on merging latest MySQL (5.1.41) into MariaDB.
After the merge, I see some test failures in the PBXT test suite. See here:
Ok, seems most of the PBXT failures are gone now. But one remains: http://askmonty.org/buildbot/reports/cross_reference#branch=5.1-merge&revision=&platform=debian5-i386-fulltest&dt=&bbnum=&typ=&info=&fail_name=pbxt.join_nested&fail_variant=&fail_info_short=&fail_info_full= (see end of mail for diff). It looks like the test is not deterministic, and chooses a slightly different execution plan between different test runs and platforms for the table t3 and t4. Do you have any suggestions about how to deal with this? - Kristian. CURRENT_TEST: pbxt.join_nested --- /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql-test/suite/pbxt/r/join_nested.result 2009-11-25 21:10:35.000000000 +0300 +++ /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql-test/suite/pbxt/r/join_nested.reject 2009-11-25 21:46:01.000000000 +0300 @@ -1008,13 +1008,13 @@ 1 SIMPLE t1 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join buffer 1 SIMPLE t2 ALL NULL NULL NULL NULL 3 100.00 Using where 1 SIMPLE t3 ALL NULL NULL NULL NULL 2 100.00 Using where -1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 Using where +1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 1 SIMPLE t5 ALL idx_b NULL NULL NULL 3 100.00 Using where 1 SIMPLE t6 ALL NULL NULL NULL NULL 3 100.00 Using where 1 SIMPLE t7 ALL NULL NULL NULL NULL 2 100.00 Using where 1 SIMPLE t8 ref idx_b idx_b 5 test.t5.b 1 100.00 Using where 1 SIMPLE t9 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join buffer -Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` AS `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS `a`,`test`.`t3`.`b` AS `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` AS `b`,`test`.`t5`.`a` AS `a`,`test`.`t5`.`b` AS `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS `b`,`test`.`t7`.`a` AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` AS `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` left join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left join (`test`.`t6` join `test`.`t7` left join `test`.`t8` on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` < 10)))) on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` >= 2)))) on((((`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and (`test`.`t1`.`a` <> 2))) join `test`.`t9` where ((`test`.`t9`.`a` = 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = 1) and ((`test`.`t2`.`a` >= 4) or isnull(`test`.`t2`.`c`)) and ((`test`.`t3`.`a` < 5) or isnull(`test`.`t3`.`c`)) and ((`test`.`t4`.`b` = `test`.`t3`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` >= 2) or isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` >= 4) or isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` <= 2) or isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` < 1) or isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) or isnull(`test`.`t8`.`c`))) +Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` AS `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS `a`,`test`.`t3`.`b` AS `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` AS `b`,`test`.`t5`.`a` AS `a`,`test`.`t5`.`b` AS `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS `b`,`test`.`t7`.`a` AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` AS `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` left join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left join (`test`.`t6` join `test`.`t7` left join `test`.`t8` on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` < 10)))) on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` >= 2)))) on((((`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and (`test`.`t1`.`a` <> 2))) join `test`.`t9` where ((`test`.`t9`.`a` = 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = 1) and ((`test`.`t2`.`a` >= 4) or isnull(`test`.`t2`.`c`)) and ((`test`.`t3`.`a` < 5) or isnull(`test`.`t3`.`c`)) and ((`test`.`t3`.`b` = `test`.`t4`.`b`) or isnull(`test`.`t3`.`c`) or isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` >= 2) or isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` >= 4) or isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` <= 2) or isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` < 1) or isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) or isnull(`test`.`t8`.`c`)))
Hi Kristian, This could be tricky. Basically, the way PBXT works this is possible, because the statistics can depend on the speed of threads running in the background. So this is likely to be a matter of timing. We will give this test a try, and see if we also get unstable results. Best regards, Paul On Nov 25, 2009, at 2:38 PM, Kristian Nielsen wrote: > Kristian Nielsen <knielsen@knielsen-hq.org> writes: > >> We are working on merging latest MySQL (5.1.41) into MariaDB. >> >> After the merge, I see some test failures in the PBXT test suite. >> See here: > > Ok, seems most of the PBXT failures are gone now. But one remains: > > http://askmonty.org/buildbot/reports/cross_reference#branch=5.1- > merge&revision=&platform=debian5-i386- > fulltest > &dt > = > &bbnum > = > &typ > = > &info > = > &fail_name > =pbxt.join_nested&fail_variant=&fail_info_short=&fail_info_full= > > (see end of mail for diff). > > It looks like the test is not deterministic, and chooses a slightly > different > execution plan between different test runs and platforms for the > table t3 and > t4. > > Do you have any suggestions about how to deal with this? > > - Kristian. > > > CURRENT_TEST: pbxt.join_nested > --- /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql- > test/suite/pbxt/r/join_nested.result 2009-11-25 21:10:35.000000000 > +0300 > +++ /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql- > test/suite/pbxt/r/join_nested.reject 2009-11-25 21:46:01.000000000 > +0300 > @@ -1008,13 +1008,13 @@ > 1 SIMPLE t1 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join > buffer > 1 SIMPLE t2 ALL NULL NULL NULL NULL 3 100.00 Using where > 1 SIMPLE t3 ALL NULL NULL NULL NULL 2 100.00 Using where > -1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 Using where > +1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 > 1 SIMPLE t5 ALL idx_b NULL NULL NULL 3 100.00 Using where > 1 SIMPLE t6 ALL NULL NULL NULL NULL 3 100.00 Using where > 1 SIMPLE t7 ALL NULL NULL NULL NULL 2 100.00 Using where > 1 SIMPLE t8 ref idx_b idx_b 5 test.t5.b 1 100.00 Using where > 1 SIMPLE t9 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join > buffer > -Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS > `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` AS > `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS `a`,`test`.`t3`.`b` AS > `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` AS `b`,`test`.`t5`.`a` AS > `a`,`test`.`t5`.`b` AS `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS > `b`,`test`.`t7`.`a` AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS > `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` AS > `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` left > join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = > `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left > join (`test`.`t6` join `test`.`t7` left join `test`.`t8` > on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` < > 10)))) on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` > >= 2)))) on((((`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and > ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and > ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or > isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and > (`test`.`t1`.`a` <> 2))) join `test`.`t9` where ((`test`.`t9`.`a` = > 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = 1) > and ((`test`.`t2`.`a` >= 4) or isnull(`test`.`t2`.`c`)) and > ((`test`.`t3`.`a` < 5) or isnull(`test`.`t3`.`c`)) and > ((`test`.`t4`.`b` = `test`.`t3`.`b`) or isnull(`test`.`t3`.`c`) or > isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` >= 2) or > isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` >= 4) or > isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` <= 2) or > isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` < 1) or > isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) or > isnull(`test`.`t8`.`c`))) > +Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS > `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` AS > `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS `a`,`test`.`t3`.`b` AS > `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` AS `b`,`test`.`t5`.`a` AS > `a`,`test`.`t5`.`b` AS `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS > `b`,`test`.`t7`.`a` AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS > `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` AS > `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` left > join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = > `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left > join (`test`.`t6` join `test`.`t7` left join `test`.`t8` > on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` < > 10)))) on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` > >= 2)))) on((((`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and > ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and > ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or > isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and > (`test`.`t1`.`a` <> 2))) join `test`.`t9` where ((`test`.`t9`.`a` = > 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = 1) > and ((`test`.`t2`.`a` >= 4) or isnull(`test`.`t2`.`c`)) and > ((`test`.`t3`.`a` < 5) or isnull(`test`.`t3`.`c`)) and > ((`test`.`t3`.`b` = `test`.`t4`.`b`) or isnull(`test`.`t3`.`c`) or > isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` >= 2) or > isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` >= 4) or > isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` <= 2) or > isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` < 1) or > isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) or > isnull(`test`.`t8`.`c`))) -- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
This has been reported as bug #489091 (https://bugs.launchpad.net/pbxt/+bug/489091 ) On Nov 26, 2009, at 5:47 PM, Paul McCullagh wrote: > Hi Kristian, > > This could be tricky. Basically, the way PBXT works this is > possible, because the statistics can depend on the speed of threads > running in the background. > > So this is likely to be a matter of timing. > > We will give this test a try, and see if we also get unstable results. > > Best regards, > > Paul > > On Nov 25, 2009, at 2:38 PM, Kristian Nielsen wrote: > >> Kristian Nielsen <knielsen@knielsen-hq.org> writes: >> >>> We are working on merging latest MySQL (5.1.41) into MariaDB. >>> >>> After the merge, I see some test failures in the PBXT test suite. >>> See here: >> >> Ok, seems most of the PBXT failures are gone now. But one remains: >> >> http://askmonty.org/buildbot/reports/cross_reference#branch=5.1- >> merge&revision=&platform=debian5-i386- >> fulltest >> &dt >> = >> &bbnum >> = >> &typ >> = >> &info >> = >> &fail_name >> =pbxt.join_nested&fail_variant=&fail_info_short=&fail_info_full= >> >> (see end of mail for diff). >> >> It looks like the test is not deterministic, and chooses a slightly >> different >> execution plan between different test runs and platforms for the >> table t3 and >> t4. >> >> Do you have any suggestions about how to deal with this? >> >> - Kristian. >> >> >> CURRENT_TEST: pbxt.join_nested >> --- /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql- >> test/suite/pbxt/r/join_nested.result 2009-11-25 21:10:35.000000000 >> +0300 >> +++ /var/lib/buildbot/maria-slave/debian5-i386-fulltest/build/mysql- >> test/suite/pbxt/r/join_nested.reject 2009-11-25 21:46:01.000000000 >> +0300 >> @@ -1008,13 +1008,13 @@ >> 1 SIMPLE t1 ALL NULL NULL NULL NULL 3 100.00 Using where; Using >> join buffer >> 1 SIMPLE t2 ALL NULL NULL NULL NULL 3 100.00 Using where >> 1 SIMPLE t3 ALL NULL NULL NULL NULL 2 100.00 Using where >> -1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 Using where >> +1 SIMPLE t4 ref idx_b idx_b 5 test.t2.b 1 100.00 >> 1 SIMPLE t5 ALL idx_b NULL NULL NULL 3 100.00 Using where >> 1 SIMPLE t6 ALL NULL NULL NULL NULL 3 100.00 Using where >> 1 SIMPLE t7 ALL NULL NULL NULL NULL 2 100.00 Using where >> 1 SIMPLE t8 ref idx_b idx_b 5 test.t5.b 1 100.00 Using where >> 1 SIMPLE t9 ALL NULL NULL NULL NULL 3 100.00 Using where; Using >> join buffer >> -Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS >> `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` >> AS `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS >> `a`,`test`.`t3`.`b` AS `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` >> AS `b`,`test`.`t5`.`a` AS `a`,`test`.`t5`.`b` AS >> `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS `b`,`test`.`t7`.`a` >> AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS >> `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` >> AS `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` >> left join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = >> `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left >> join (`test`.`t6` join `test`.`t7` left join `test`.`t8` >> on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` < >> 10)))) on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` >> >= 2)))) on((((`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and >> ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and >> ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or >> isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and >> (`test`.`t1`.`a` <> 2))) join `test`.`t9` where ((`test`.`t9`.`a` = >> 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = >> 1) and ((`test`.`t2`.`a` >= 4) or isnull(`test`.`t2`.`c`)) and >> ((`test`.`t3`.`a` < 5) or isnull(`test`.`t3`.`c`)) and >> ((`test`.`t4`.`b` = `test`.`t3`.`b`) or isnull(`test`.`t3`.`c`) or >> isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` >= 2) or >> isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` >= 4) or >> isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` <= 2) or >> isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` < 1) or >> isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) >> or isnull(`test`.`t8`.`c`))) >> +Note 1003 select `test`.`t0`.`a` AS `a`,`test`.`t0`.`b` AS >> `b`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t2`.`a` >> AS `a`,`test`.`t2`.`b` AS `b`,`test`.`t3`.`a` AS >> `a`,`test`.`t3`.`b` AS `b`,`test`.`t4`.`a` AS `a`,`test`.`t4`.`b` >> AS `b`,`test`.`t5`.`a` AS `a`,`test`.`t5`.`b` AS >> `b`,`test`.`t6`.`a` AS `a`,`test`.`t6`.`b` AS `b`,`test`.`t7`.`a` >> AS `a`,`test`.`t7`.`b` AS `b`,`test`.`t8`.`a` AS >> `a`,`test`.`t8`.`b` AS `b`,`test`.`t9`.`a` AS `a`,`test`.`t9`.`b` >> AS `b` from `test`.`t0` join `test`.`t1` left join (`test`.`t2` >> left join (`test`.`t3` join `test`.`t4`) on(((`test`.`t4`.`b` = >> `test`.`t2`.`b`) and (`test`.`t3`.`a` = 1))) join `test`.`t5` left >> join (`test`.`t6` join `test`.`t7` left join `test`.`t8` >> on(((`test`.`t8`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` < >> 10)))) on(((`test`.`t7`.`b` = `test`.`t5`.`b`) and (`test`.`t6`.`b` >> >= 2)))) on((((`test`.`t3`.`b` = 2) or isnull(`test`.`t3`.`c`)) and >> ((`test`.`t6`.`b` = 2) or isnull(`test`.`t6`.`c`)) and >> ((`test`.`t5`.`b` = `test`.`t0`.`b`) or isnull(`test`.`t3`.`c`) or >> isnull(`test`.`t6`.`c`) or isnull(`test`.`t8`.`c`)) and >> (`test`.`t1`.`a` <> 2))) join `test`.`t9` where ((`test`.`t9`.`a` = >> 1) and (`test`.`t1`.`b` = `test`.`t0`.`b`) and (`test`.`t0`.`a` = >> 1) and ((`test`.`t2`.`a` >= 4) or isnull(`test`.`t2`.`c`)) and >> ((`test`.`t3`.`a` < 5) or isnull(`test`.`t3`.`c`)) and >> ((`test`.`t3`.`b` = `test`.`t4`.`b`) or isnull(`test`.`t3`.`c`) or >> isnull(`test`.`t4`.`c`)) and ((`test`.`t5`.`a` >= 2) or >> isnull(`test`.`t5`.`c`)) and ((`test`.`t6`.`a` >= 4) or >> isnull(`test`.`t6`.`c`)) and ((`test`.`t7`.`a` <= 2) or >> isnull(`test`.`t7`.`c`)) and ((`test`.`t8`.`a` < 1) or >> isnull(`test`.`t8`.`c`)) and ((`test`.`t9`.`b` = `test`.`t8`.`b`) >> or isnull(`test`.`t8`.`c`))) > > > > -- > Paul McCullagh > PrimeBase Technologies > www.primebase.org > www.blobstreaming.org > pbxt.blogspot.com > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-developers > Post to : maria-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-developers > More help : https://help.launchpad.net/ListHelp -- Paul McCullagh PrimeBase Technologies www.primebase.org www.blobstreaming.org pbxt.blogspot.com
participants (3)
-
Kristian Nielsen -
Paul McCullagh -
Vladimir Kolesnikov