public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michail Nikolaev <[email protected]>
To: PostgreSQL Hackers <[email protected]>
To: Andres Freund <[email protected]>
Subject: Re: [BUG?] check_exclusion_or_unique_constraint false negative
Date: Sun, 21 Jul 2024 17:27:01 +0200
Message-ID: <CANtu0ohU2XRV9shtu14CffLPDS1x10q7ebOGf-vX0p+45_L8jw@mail.gmail.com> (raw)
In-Reply-To: <CANtu0oiktqQ2pwExoXqDpByXNCJa-KE5vQRodTRnmFHN_+qwHg@mail.gmail.com>
References: <CANtu0oiktqQ2pwExoXqDpByXNCJa-KE5vQRodTRnmFHN_+qwHg@mail.gmail.com>
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
>
view thread (2+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [BUG?] check_exclusion_or_unique_constraint false negative
In-Reply-To: <CANtu0ohU2XRV9shtu14CffLPDS1x10q7ebOGf-vX0p+45_L8jw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox