CockroachDB 1.0.5 fixes foreign-key checks on index prefixes
A foreign-key lookup encoded too many index columns and could miss dependent rows during deletion. The existing test's null values concealed the defect.
A test can exercise the right operation with data that accidentally makes faulty code succeed. CockroachDB 1.0.5 fixes a foreign-key enforcement bug whose existing test had exactly that problem. The lookup used too many columns when a foreign key occupied a prefix of an existing index. Null values in the test's trailing positions happened to match the incorrectly encoded key.
The August 24 release notes describe the consequence. A row could be deleted from the referenced table even though another table still referred to it. Version 1.0.5 corrects enforcement for this index-prefix case and fixes the corresponding foreign-key output from SHOW CREATE TABLE.
I value relational constraints because they let the database enforce relationships independently of every caller's application logic. That makes a missed foreign-key check a correctness issue even when no query crashes. The stored relationship remains declared, but a deletion can leave data that violates it.
The lookup key had the index's full width
The backported fix, merged August 15, explains the encoding error. The lookup into the referencing index used the full number of columns in that index, although the foreign key covered fewer columns. Encoding the additional positions introduced trailing null values into the key.
The check needed to find rows whose foreign-key columns referred to the row being deleted. Extending the lookup with unintended trailing values narrowed what it could match. A dependent row could therefore exist without appearing under the incorrect key used for the check.
This is an index-prefix problem, not a general statement that every foreign key failed. The affected relationship used only an initial part of an already existing index. The implementation had to preserve that narrower key width when searching the index for dependent rows.
The pull request says tables created on 1.0 and earlier versions with this arrangement might contain violations if rows were deleted from the referenced table. That is a statement about existing data as well as future execution. Installing corrected lookup code prevents that faulty check on later operations, but does not recreate a referenced row already deleted.
Null test data concealed the extra columns
The test intended to guard this behavior included null values in the trailing positions of the referencing key. The faulty encoder also supplied nulls in those positions. It consequently found a match in the test, and deletion was prevented as expected.
That result gave the test the right observable outcome for the wrong lookup construction. Non-null trailing data exposed the difference between matching a foreign-key prefix and matching the entire index key. The failure was therefore sensitive to data choices within the already relevant schema arrangement.
This explains why merely pointing to a foreign-key test would not establish coverage of the defect. The operation, relationship, and index could all be present while the selected values erased the difference the test needed to observe. The implementation discussion identifies the accidental equality explicitly.
I find this more useful than a general instruction to add more tests. The missing case is precise, trailing values that do not match the erroneous padding. A regression check needs to distinguish the intended prefix search from the full-width key the old code constructed.
Schema output must describe the same relationship
The fix also corrects SHOW CREATE TABLE for these foreign keys. Schema introspection is part of the practical database contract because tooling can use the emitted definition to understand or reconstruct a table. Incorrect output can misrepresent the relationship even when the caller is not currently deleting data.
Both repairs concern the same distinction between a foreign key's columns and the larger index used to support it. Enforcement needs the correct lookup width. Schema output needs the correct definition of the declared relationship. Treating the supporting index as though every column belonged to the foreign key loses that distinction in two places.
The source does not give a universal data-repair command for affected installations. It identifies a condition under which previous deletions may have left violations. Any account of this update should preserve that condition instead of implying binary replacement proves every stored relationship is already valid.
Failure reporting receives separate operational fixes
Fatal error messages now go to both standard error and the logs. The crash reporter also gains a timeout instead of potentially waiting forever to reach its server. These changes concern what happens when an operation has already failed, rather than changing foreign-key semantics.
The release additionally converts AS OF SYSTEM TIME 0 from a panic into an ordinary error and removes 3DES from the configured TLS cipher list. Its notes say that cipher was not selected under the existing TLS 1.2 requirement but could trigger scanner reports. The main relational correction remains the prefix lookup, with existing-data implications tied specifically to prior deletions under the affected foreign-key arrangement.