CURRENT_TEST: pbxt.preload

--- /home/knielsen/devel/maria/my/work-5.1-mysqltest/mysql-test/suite/pbxt/r/preload.result	2010-05-26 09:39:54.000000000 +0200

+++ /home/knielsen/devel/maria/my/work-5.1-mysqltest/mysql-test/suite/pbxt/r/preload.reject	2010-10-29 21:12:28.000000000 +0200

@@ -40,10 +40,10 @@

 insert into t1(b) select b from t2;

 select count(*) from t1;

 count(*)

-33448

+33440

 select count(*) from t2;

 count(*)

-20672

+20668

 flush tables;

 flush status;

 show status like "key_read%";

This failure is not deterministically reproducable, only happens rarely. But
we've seen it occasionally in our Buildbot over time:

http://buildbot.askmonty.org/buildbot/reports/cross_reference#branch=&revision=&platform=&dt=&bbnum=&typ=&info=&fail_name=pbxt.preload&fail_variant=&fail_info_short=&fail_info_full=&limit=100

I was able to repeat as follows in latest MariaDB 5.1:

(cd mysql-test && for i in `seq 1 1000` ; do ./mtr --parallel=3 pbxt.preload pbxt.preload pbxt.preload || exit 1 ; done)

However, the failure seems to be quite elusive, so YMMV...

The failure looks quite strange, the test just inserts a bunch of rows and
then SELECT COUNT( * ) from the tables return a few rows too few.

I am speculating if this could be caused by the PBXT engine returning some
statistics about table size to mysqld, which is then taken by the optimiser as the actual count, so it optimises away a table scan? Either by mistake (so the fix would be to have PBXT tell mysqld that the count returned is an estimate only), or deliberately (so something would be wrong with the accuracy of the optimised row count)?