Re: [BUG?] check_exclusion_or_unique_constraint false negative

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [BUG?] check_exclusion_or_unique_constraint false negative
Дата
Msg-id CAA4eK1+7bNcjF5gRnfACgLMq1VPKQdD8fR43Rd93wdMzLqCbdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUG?] check_exclusion_or_unique_constraint false negative  (Mihail Nikalayeu <mihailnikalayeu@gmail.com>)
Список pgsql-hackers
On Mon, Aug 25, 2025 at 7:02 PM Mihail Nikalayeu
<mihailnikalayeu@gmail.com> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com>:
>
>
> > What if the new insert happens in a page prior to the current page? I
> > mean that the scan won't encounter the page where Insert happens.
>
> Hmm.... Yes - if the TID lands to the page left of the current
> position, we’ll miss it as well.
> A lock‑based solution (version in the v10) would require keeping all
> pages with the same key under a read lock, which feels too expensive.
>

Right.

> > BTW, do we know the reason behind using SnapshotDirty in the first
> > place? I don't see any comments in the nearby code unless I am missing
> > something.
>
> I think this is simply an attempt to lock the newest version of the
> logical tuple, including INSERT cases.
> For an existing tuple, the same can be achieved using MVCC snapshot + retry.
> However, in the case of a not-yet-committed INSERT, a different type
> of snapshot is required.
>
> But I'm not sure if it provides any advantages.
>

I think it is better to document this race somewhere in a logical
replication document for now unless we have a consensus on a way to
move forward.

--
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления: