| Bug #46897 | Test "index_merge_innodb" fails (mostly) | ||
|---|---|---|---|
| Submitted: | 24 Aug 2009 15:56 | Modified: | 16 Sep 2009 16:52 |
| Reporter: | Joerg Bruehe | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Tests | Severity: | S3 (Non-critical) |
| Version: | 5.4 | OS: | Any |
| Assigned to: | Guilhem Bichot | CPU Architecture: | Any |
[24 Aug 2009 16:07]
Joerg Bruehe
Maybe this is helpful: I do my local runs using "make -k test-force" which means the suite is run twice, first in "normal" mode and then using "--ps-protocol". Here are the results: 1) Pegasos (PowerPC): main.index_merge_innodb [ fail ] main.index_merge_innodb [ retry-fail ] main.index_merge_innodb [ fail ] main.index_merge_innodb [ retry-fail ] 2) Tower (Athlon): main.index_merge_innodb [ fail ] main.index_merge_innodb [ retry-pass ] 19254 main.index_merge_innodb [ retry-pass ] 15160 main.index_merge_innodb [ pass ] 15820 3) Notebook (Pentium): main.index_merge_innodb [ fail ] main.index_merge_innodb [ retry-fail ] main.index_merge_innodb [ pass ] 10823
[25 Aug 2009 15:54]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/81527 2872 Guilhem Bichot 2009-08-25 fix for Bug#46897 'Test "index_merge_innodb" fails (mostly)': that was already analyzed by Oracle: EXPLAIN can return 3 or 4 in "rows"; using replace_column to work around this. @ mysql-test/include/index_merge2.inc replace "rows" column of some EXPLAINs by "#", if told so @ mysql-test/r/index_merge_innodb.result result update @ mysql-test/t/index_merge_innodb.test tell index_merge2.inc to accept random "rows" values in some EXPLAINs; we don't do this in index_merge_myisam.test which has no randomness here.
[25 Aug 2009 15:55]
Guilhem Bichot
queued to mysql-trunk
[25 Aug 2009 15:59]
Guilhem Bichot
sorry, queued to mysql-trunk-bugfixing, not to mysql-trunk
[26 Aug 2009 8:15]
Guilhem Bichot
It's not a bug in the Server or InnoDB; it's just that, as explained by Oracle, a change in InnoDB statistics computation has the consequence that the "rows" column in EXPLAIN, in test index_merge_innodb.test, can now be one of (3,4) instead of always 4. That is, we just need to adjust the test to tolerate this, and this is what I did in mysql-trunk-bugfixing. And I passed the patch to Svoj, who faces a similar problem in 5.1-main.
[27 Aug 2009 16:56]
Joerg Bruehe
I am just doing an upmerge from 5.1 to 5.4, to test it locally. In 5.1, this test was specifically disabled from being run with the InnoDB plugin, coded in the Perl tools where the plugin was handled. This part of the code is not present in 5.4, so I upmerged the effect by adding this test to "disabled.def". When you push your fix, please check "disabled.def" whether this test is still contained.
[28 Aug 2009 11:44]
Joerg Bruehe
The proper fix was pushed to the main branch well before my merge, so my note about "disabled.def" is obsolete - it never left my local test area.
[15 Sep 2009 19:54]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83366 2853 Alexander Nozdrin 2009-09-15 [merge] Null-merge of the patch for Bug#46897 from mysql-trunk into mysql-next (6.0). The bug is specific to the InnoDB plugin, it hasn't happened in 6.0.
[16 Sep 2009 6:16]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83410 2852 Alexander Nozdrin 2009-09-16 [merge] Null-merge mysql-trunk up to revno:2872 (a patch for Bug#46897). The bug is specific to the InnoDB plugin, it hasn't happened in 6.0.
[16 Sep 2009 6:45]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090916063112-8hjmu6wkxfx5qxf4) (version source revid:alik@sun.com-20090916061447-6yz0x330meriavsu) (merge vers: 5.4.4-alpha) (pib:11)
[16 Sep 2009 16:52]
Paul DuBois
Test case changes. No changelog entry needed.
Description: I observe this test failure in all my 5.4 builds + tests (Linux/x86 + Linux/PowerPC, 32-bit). However, sometimes the test passes on retry, so there is some instability involved. Current 5.1 builds do not show this issue, so it might depend on the InnoDB version included. Symptom: ===== main.index_merge_innodb [ fail ] Test ended at 2009-08-19 16:07:40 CURRENT_TEST: main.index_merge_innodb --- /MySQL/REPO/V54/work-5.4/mysql-test/r/index_merge_innodb.result 2009-08-19 13:41:22.000000000 +0300 +++ /MySQL/REPO/V54/work-5.4/mysql-test/r/index_merge_innodb.reject 2009-08-19 17:07:39.000000000 +0300 @@ -111,7 +111,7 @@ explain select count(*) from t1 where key1a = 2 and key1b is null and key2a = 2 and key2b is null; id select_type table type possible_keys key key_len ref rows Extra -1 SIMPLE t1 index_merge i1,i2 i1,i2 10,10 NULL 4 Using intersect(i1,i2); Using where; Using index +1 SIMPLE t1 index_merge i1,i2 i1,i2 10,10 NULL 3 Using intersect(i1,i2); Using where; Using index select count(*) from t1 where key1a = 2 and key1b is null and key2a = 2 and key2b is null; count(*) @@ -119,7 +119,7 @@ explain select count(*) from t1 where key1a = 2 and key1b is null and key3a = 2 and key3b is null; id select_type table type possible_keys key key_len ref rows Extra -1 SIMPLE t1 index_merge i1,i3 i1,i3 10,10 NULL 4 Using intersect(i1,i3); Using where; Using index +1 SIMPLE t1 index_merge i1,i3 i1,i3 10,10 NULL 3 Using intersect(i1,i3); Using where; Using index select count(*) from t1 where key1a = 2 and key1b is null and key3a = 2 and key3b is null; count(*) mysqltest: Result content mismatch ===== How to repeat: For me, it happens in each 5.4 run. Suggested fix: Searching the bugs DB, I find bug#8003 which looks pretty similar but was closed in January, 2005