FirebirdSQL
Conflict resolution code uses constraint name instead of index name
https://github.com/FirebirdSQL/firebird/blame/95442bdfff76d22aafb57b58894047be2a89c6ea/src/jrd/replication/Applier.cpp#L637
If these names are different debug build consistently throw assertion error during execution of test_blob_not_found_in_rw_replica_if_target_row_exists.py.
The issue makes no real problem: if code can't find index - it works as before #8042. The only visible problem is assertions in DEBUG build.
Anyway, I'll look how to better handle the case when index and constraint names are not the same.
Read the code and stop speculate:
https://github.com/FirebirdSQL/firebird/blame/95442bdfff76d22aafb57b58894047be2a89c6ea/src/jrd/replication/Applier.cpp#L1111
Read the code and stop speculate:
It was the reply on (lost, deleted ?) comment by aafemt: "I wonder what could happen if there is index with name matched constraint's one but on different table..."
In the commit above, I removed the extra fb_assert, which is already in the haveIdx variable, and also add lookup index name by the constraint name, which in the isc_unique_key_violation error occurs.
This is a rare case, but if the constraint name matches another index name in the same table, then lookupRecord will not work correctly and a repeated attempt to insert a record will lead to a replication error, for example in this case:
create table test_table (
id integer constraint rdb$2 unique using index rdb$1,
id2 integer constraint rdb$1 unique using index rdb$2,
name varchar(20)
);
Why not create PR ? It is at least inconvenient to comment commit in external repository. Or your just wanted to show it ? :)
I didn't want to create a separate PR when it can be simply pushed to those who have the right to directly commit. Otherwise, the problem will have two issue numbers. :) I'll create a PR now -> #8586
::: QA note ::: See tests/functional/replication/test_uk_violation_in_rw_repl_if_constraint_name_is_used.py
