Bug #36851 NDBAPI : IgnoreError with Insert operation and Blobs
Submitted: 21 May 14:17 Modified: 30 May 16:12
Reporter: Frazer Clement
Status: Closed
Category:Server: NDBAPI Severity:S3 (Non-critical)
Version:All OS:Any
Assigned to: Frazer Clement Target Version:

[21 May 14:17] Frazer Clement 
Description:
When fixing bug # 36756, it was observed that when an insert operation is attempted on a
row which already exists, and the insert involves Blob data, incorrect behaviour results.

The Duplicate key error is not correctly reported and the transaction is incorrectly
aborted.  In the case where the Blob length is < the inline Blob header size, the existing
row can become corrupted by the second attempted insert.

How to repeat:
Remove special casing in testBlobs.cpp and observe that execute() rc, Transaction error
code, operation error codes and transaction commitstatus are not as observed.

Suggested fix:
Where the main insert operation is executed with IgnoreError, avoid adding Blob part
insert operations and head update operations until the Blob head has been successfully
read.
[23 May 12:20] Bugs System 
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/46989

ChangeSet@1.2601, 2008-05-23 11:20:10+01:00, frazer@forth.ndb.mysql.com +2 -0
  Bug#36851 : Insert, IgnoreError and Blobs
  
  Where an Insert has IgnoreError abortOption, don't initiate head and part update
operations until 
  Insert operation has succeeded.
  This avoids trampling the Blob head or unwanted transaction abort on the Blob part
operations.
[23 May 12:44] Bugs System 
Pushed into 5.1.23-ndb-6.4.0
[23 May 12:48] Bugs System 
Pushed into 5.1.24-ndb-6.3.15
[23 May 12:51] Bugs System 
Pushed into 5.1.24-ndb-6.2.16
[30 May 16:12] Jon Stephens 
Documented in the 5.1.24-ndb-6.2.16 and 5.1.24-ndb6.3.15 changelogs as follows:

        When an insert operation involving BLOB data was attempted on a row
        which already existed, no duplicate key error was correctly reported and
        the transaction is incorrectly aborted. In some cases, the existing
        row could also become corrupted.