[DERBY-6665] Violation of deferred constraints not detected when conglomerates are erroneously shared

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 10.11.1.1
• Fix Version/s: 10.11.1.1
• Component/s: SQL
• Labels: derby_backport_reject_10_10
• Urgency: Blocker
• Bug behavior facts: Data corruption, Wrong query result
• Assignee: Dag H. Wanvik
• Reporter: Knut Anders Hatlen
• Created: 15/Jul/14 22:42
• Updated: 09/Sep/16 09:52
• Resolved: 30/Jul/14 12:31

Description

See the following script:

ij version 10.11
ij> connect 'jdbc:derby:memory:db;create=true';
ij> create table t1(x int primary key);
0 rows inserted/updated/deleted
ij> create table t2(x int primary key);
0 rows inserted/updated/deleted
ij> create table t3(x int, constraint fk1 foreign key (x) references t1 initially deferred, constraint fk2 foreign key (x) references t2 initially deferred);
0 rows inserted/updated/deleted
ij> insert into t1 values 1;
1 row inserted/updated/deleted
ij> autocommit off;
ij> insert into t3 values 1;
1 row inserted/updated/deleted
ij> insert into t2 values 1;
1 row inserted/updated/deleted
ij> delete from t1;
1 row inserted/updated/deleted
ij> commit;
ij> select * from t1;
X          
-----------

0 rows selected
ij> select * from t2;
X          
-----------
1          

1 row selected
ij> select * from t3;
X          
-----------
1          

1 row selected

Since T3.X contains a value (1) that is not present in T1, the foreign key FK1 is violated, and the COMMIT statement should have failed.

Issue Links

• is related to: DERBY-6668 Truncating a table may silently violate a deferred foreign key.
• is related to: DERBY-6670 Rollback to savepoint allows violation of deferrable constraints
• is related to: DERBY-6674 Cleanup brittle code in ValidateCheckConstraintResultSet