Обсуждение: [BUG?] check_exclusion_or_unique_constraint false negative
Hello, everyone!
While reviewing [1], I noticed that check_exclusion_or_unique_constraint occasionally returns false negatives for btree unique indexes during UPSERT operations.
Although this doesn't cause any real issues with INSERT ON CONFLICT, I wanted to bring it to your attention, as it might indicate an underlying problem.
Attached is a patch to reproduce the issue.
Attached is a patch to reproduce the issue.
make -C src/test/modules/test_misc/ check PROVE_TESTS='t/006_*'
....
Failed test 'concurrent INSERTs status (got 2 vs expected 0)'
# at t/006_concurrently_unique_fail.pl line 26.
# Failed test 'concurrent INSERTs stderr /(?^:^$)/'
# at t/006_concurrently_unique_fail.pl line 26.
# 'pgbench: error: client 34 script 0 aborted in command 0 query 0: ERROR: we know 31337 in the index!
# at t/006_concurrently_unique_fail.pl line 26.
# Failed test 'concurrent INSERTs stderr /(?^:^$)/'
# at t/006_concurrently_unique_fail.pl line 26.
# 'pgbench: error: client 34 script 0 aborted in command 0 query 0: ERROR: we know 31337 in the index!
Best regards,
Mikhail,
Вложения
Hello, Andres.
Sorry to bother you, but I feel it's necessary to validate the possible issue regarding someone who can decide whether it is okay or not.
The issue is reproducible with the first UPSERT implementation (your commit 168d5805e4c08bed7b95d351bf097cff7c07dd65 from 2015) and up to now.
The problem appears as follows:
* A unique index contains a specific value (in the test, it is the only value for the entire index).
* check_exclusion_or_unique_constraint returns FALSE for that value in some random cases.
* Technically, this means index_getnext finds 0 records, even though we know the value exists in the index.
I was able to reproduce this only with an UNLOGGED table.
I can't find any scenarios that are actually broken (since the issue is resolved by speculative insertion later), but this looks suspicious to me. It could be a symptom of some tricky race condition in the btree.
Best regards,
Mikhail
Sorry to bother you, but I feel it's necessary to validate the possible issue regarding someone who can decide whether it is okay or not.
The issue is reproducible with the first UPSERT implementation (your commit 168d5805e4c08bed7b95d351bf097cff7c07dd65 from 2015) and up to now.
The problem appears as follows:
* A unique index contains a specific value (in the test, it is the only value for the entire index).
* check_exclusion_or_unique_constraint returns FALSE for that value in some random cases.
* Technically, this means index_getnext finds 0 records, even though we know the value exists in the index.
I was able to reproduce this only with an UNLOGGED table.
I can't find any scenarios that are actually broken (since the issue is resolved by speculative insertion later), but this looks suspicious to me. It could be a symptom of some tricky race condition in the btree.
Best regards,
Mikhail
Hello, everyone!
Updates so far:
* issue happens with both LOGGED and UNLOGGED relations
* issue happens with DirtySnapshot
* not happens with SnapshotSelf
* not happens with SnapshotAny
* not related to speculative inserted tuples - I have commented the code of its insertion - and the issue continues to occur.
Best regards,
Mikhail.