MySQL Bugs: #33739: Bug in TUP-SCAN

Bug #33739	Bug in TUP-SCAN
Submitted:	8 Jan 2008 12:19	Modified:	20 Feb 2008 21:45
Reporter:	Jonas Oreland	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:		OS:	Any
Assigned to:	Jonas Oreland	CPU Architecture:	Any
Tags:	5.1->

Description:
If TUP-SCAN gets timesliced.
The page is not refetched.

For DD, this can mean that we access incorrect page.
  as it can have been evicted when re-entering

For MM with page-release, this can mean that we access incorrect page.
  as it can have been released when re-entering

How to repeat:
autotest repeats MM-with page release

Suggested fix:
reset state to Get_page on entering scanNext

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/40676

ChangeSet@1.2528, 2008-01-08 13:23:35+01:00, jonas@perch.ndb.mysql.com +1 -0
  ndb - bug#33739
    page need to refetched after timeslice

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/40681

ChangeSet@1.2829, 2008-01-08 14:21:17+01:00, jonas@perch.ndb.mysql.com +1 -0
  ndb - bug#33739
    Additional fix for bug#33739 (63 and upwards)
    reset realpid_mm to cater for page being released

pushed to 51-telco-gca, 51-ndb, telco-6.1, telco-6.2, telco-6.3, telco-6.4

Documented in 5.1.23-ndb-6.2.11 and 5.1.23-ndb-6.3.8 changelogs as follows:

        Some tuple scans caused the wrong memory page to be accessed,
        leading to invalid results. This issue could affect both
        in-memory and Disk Data tables.

Left bug status as PQ, pending additional merges.

Pushed into 5.1.24-rc

Pushed into 6.0.5-alpha

Also documented for 5.1.24 and 6.0.5.