Wrong result for SELECT COUNT(*) FROM t in pbxt.preload

[Kristian Nielsen]

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)?