Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.5.11, 10.5.12
-
debian unstable
Description
Hi
I have table corruption caught by check table.
I narrowed my ~400M rows table to a single integer column. The error happens after index creation if you run check table.
I managed to recreate it with a random set of 70K values distributed in 400M rows.
See the attached script. It completes in 32' in my system (oldish xeon with NVM) and it fails
with
--------------
|
CHECK TABLE bugtable
|
--------------
|
|
|
+---------------+-------+-------+------------------------------------------+
|
| budb.bugtable | check | error | Key in wrong position at page 1023494144 | |
| budb.bugtable | check | error | Corrupt |
|
+---------------+-------+-------+------------------------------------------+
|
2 rows in set (38.701 sec) |
|
The script is easily run with:
time ./mysql-index-corruption-bug.sh bugdb bugtable;
|
Attachments
Issue Links
- relates to
-
-
- Confirmed
-
Activity
First of all - my bad
It was a configuration error after all.
I upgraded to 10.6.4 and the bug persists. Since I had other machines with 10.6.4 where the bug doesn't manifest I thought it must be an error in configuration.
Indeed I checked again and lo and behold I spot this
sort-buffer-size = 8G
It was supposed to be 8M.
So I switched it to 8M and everything works now.
Maybe this situation warrants a warning...
Sorry for the noise.
Vassilis
I think I found another manifestation of this bug.
GROUP BY fails to produce unique output (produces duplicate rows) in filesort mode.
I theorize that this is because when in filesort mode it first creates a sort index and that part fails.
Further experimentation showed that the bug manifests when the number of rows are more than 390136719 (lower than 390039063 works)
Finally the bug does not exists in 10.6.4
How to replicate this one: check the replicator script ./mariadb-groupby-fails-bug.sh
You can run it with
./mariadb-groupby-fails-bug.sh database bugtable
I would be great to know
a) the commit that fixed the issue
b) if a test that could guard against this could be devised?
Vassilis