| From: | Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: [BUG?] check_exclusion_or_unique_constraint false negative |
| Date: | 2025-08-25 13:32:03 |
| Message-ID: | CADzfLwUqZ_s9FzonE-z0REOm8Q0aDVJh_W8S1r9vTYSwBLHo+g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2025-08-25 13:33:17 | Re: [PATCH] Generate random dates/times in a specified range |
| Previous Message | Kirill Reshke | 2025-08-25 13:29:46 | Re: Fix ALTER TABLE DROP EXPRESSION with inheritance hierarchy |