Wrong result for SELECT COUNT(*) FROM t in pbxt.preload
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MariaDB |
New
|
Undecided
|
Unassigned | ||
PBXT |
In Progress
|
Undecided
|
Vladimir Kolesnikov |
Bug Description
CURRENT_TEST: pbxt.preload
--- /home/knielsen/
+++ /home/knielsen/
@@ -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:
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 |