Bug #81934 Reading wrong length of varsize in LCP handling at times
Submitted: 20 Jun 2016 13:03 Modified: 8 Jul 2016 9:24
Reporter: Mikael Ronström Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:7.5.3 OS:Any
Assigned to: CPU Architecture:Any

[20 Jun 2016 13:03] Mikael Ronström
Description:
When performing an LCP we have to ensure that all rows that were around at the time of the LCP are also present in the
LCP. This means that we need to perform the LCP of this row immediately at the time of a delete operation on this row.
We create the original row in the copy tuple part for the delete. However when doing so we can come across the header
bit MM_GROWN being set. If so we should not read varpart length from page entry but rather from end of varpart.
This is not done and rather we have an ndbassert to ensure that MM_GROWN isn't set. However MM_GROWN can be set in this
case if an UPDATE operation preceeded the DELETE in the same transaction on the same row.

The consequence of this is that the varsize part becomes too long in the restore. It should not really have any
consequence given that we should delete the row again soon enough.

How to repeat:
Execute test case testIndex -n DeferredMixedLoadError --skip-ndb-optimized-node-selection T6 T13

Suggested fix:
Update code to read the correct length, change ndbassert to ndbrequire for case where MM_GROWN should not happen
[8 Jul 2016 9:24] Jon Stephens
Fixed in NDB 7.5.4. As this bug did not have any user-visible effects, no changelog entry is needed. 

Closed.