Bug #80733 | Acc table scan may scan same row twice | ||
---|---|---|---|
Submitted: | 14 Mar 2016 18:21 | Modified: | 12 May 2016 5:39 |
Reporter: | Mauritz Sundell | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S3 (Non-critical) |
Version: | 7.4.10 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[14 Mar 2016 18:21]
Mauritz Sundell
[14 Mar 2016 18:25]
Mauritz Sundell
Posted by developer: This bug should be fixed in 7.2 and up. Even if acc scan do not guarantee that a deleted row and an inserted row with same key are not scanned twice. It is severe that rows that are neither deleted or inserted during scan are scanned twice!
[18 Mar 2016 15:24]
Mauritz Sundell
Posted by developer: Another related bug. If one have scanned some buckets and then let table expand. If the split bucket is below current bucket, the new top bucket should be treated as scanned. But if one let table shrink again, scan bits of top bucket are cleared before merge, and merge bucket are marked for rescan. Continuing the scan it may scan some rows twice.
[12 May 2016 5:39]
Jon Stephens
Documented fix in the NDB 7.5.2 changelog as follows: A table scan using neither an ordered index nor any Disk Data columns normally uses an ACC scan. If this happened while scanning an unique but unordered index which shrank (due to rows being deleted) after the scan started and then grew again (rows inserted), a single row that had been neither deleted nor inserted could be scanned twice. Closed.