BLOB fields may be suddenly set to NULLs during UPDATE after a table format
change
----------------------------------------------------------------------------------
Key: CORE-6090
URL: http://tracker.firebirdsql.org/browse/CORE-6090
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 4.0 Beta 1, 3.0.4, 3.0.3
Reporter: Dmitry Yemanov
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
