Issue Details (XML | Word | Printable)

Key: CORE-6090
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Dmitry Yemanov
Reporter: Dmitry Yemanov
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

BLOB fields may be suddenly set to NULLs during UPDATE after a table format change

Created: 29/Jun/19 09:14 AM   Updated: 06/Jul/19 09:37 AM
Component/s: Engine
Affects Version/s: 3.0.3, 3.0.4, 4.0 Beta 1
Fix Version/s: 3.0.5, 4.0 Beta 2

Issue Links:
Relate
 

QA Status: Done successfully


 Description  « Hide
Test case:

recreate table t (col1 int, col2 int, col3 int, col4 blob);

insert into t values (0, 0, null, '0');
insert into t values (1, 1, 1, '1');
insert into t values (2, 2, 2, '2');
commit;

select * from t;

        COL1 COL2 COL3 COL4
============ ============ ============ =================
           0 0 <null> 83:0
           1 1 1 83:1
           2 2 2 83:2


update t set col1 = 1 where col2 >= 0;
-- COL1 should be set to 1 in all three rows
select * from t;

        COL1 COL2 COL3 COL4
============ ============ ============ =================
           1 0 <null> 83:0
           1 1 1 83:1
           1 2 2 83:2

rollback;

update t set col1 = 1 where col2 >= 0 and col3 >= 0;
-- COL1 should be set to 1 in 2nd and 3rd rows
select * from t;

        COL1 COL2 COL3 COL4
============ ============ ============ =================
           0 0 <null> 83:0
           1 1 1 83:1
           1 2 2 83:2

rollback;

alter table t add col5 date;
commit;

update t set col1 = 1 where col2 >= 0;
-- COL1 should be set to 1 in all three rows
select * from t;

        COL1 COL2 COL3 COL4 COL5
============ ============ ============ ================= ===========
           1 0 <null> 83:3 <null>
           1 1 1 83:4 <null>
           1 2 2 83:5 <null>

-- BLOB IDs in COL4 were changed (see CORE-6089) but contents is correct

rollback;

update t set col1 = 1 where col2 >= 0 and col3 >= 0;
-- COL1 should be set to 1 in 2nd and 3rd rows
select * from t;

        COL1 COL2 COL3 COL4 COL5
============ ============ ============ ================= ===========
           0 0 <null> 83:0 <null>
           1 1 1 <null> <null>
           1 2 2 83:6 <null>

-- BUG: COL4 in the second row was nullified!!!

rollback;

This issue manifests itself this way: if some WHERE condition (COL3 >= 0 in our case) is evaluated to NULL/UNKNOWN for the prior (skipped) row, then all blobs are set to NULLs in the next row (unless explicitly set to something else by the SET clause). This happens only for BLOB fields and only if OLD and NEW records have different formats (i.e. after ALTER TABLE).

The bug became visible after fixing CORE-5600 (thus v3.0.3 and later versions are affected), but the issue itself seems to be old. We were just lucky that the "buggy" code path was never used before.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.