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

Bug #668491 reported by Kristian Nielsen
This bug affects 1 person
Affects Status Importance Assigned to Milestone
In Progress
Vladimir Kolesnikov

Bug Description

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;
 select count(*) from t2;
 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:


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

Changed in pbxt:
status: New → Confirmed
Changed in maria:
milestone: none → 5.1
Changed in pbxt:
assignee: nobody → Vladimir Kolesnikov (vkolesnikov)
status: Confirmed → In Progress
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers