| From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
|---|---|
| To: | Amit Langote <amitlan(at)postgresql(dot)org> |
| Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Lock RI fast-path rows as of the scan snapshot's command ID |
| Date: | 2026-10-08 04:43:20 |
| Message-ID: | CA+HiwqH=D4d_SRZoo4fnE-sKRu_DO8UjJMyhATgaBcFUu7ANRg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On Thu, Oct 8, 2026 at 12:50 PM Amit Langote <amitlan(at)postgresql(dot)org> wrote:
> This is mostly hardening. With FK values that need a cast now checked
> through SPI, the only user code that can run there is the opclass's
> equality function, and it would have to write to the referenced table.
> That's unlikely, but the fast path should still behave like SPI.
Oops, the "FK values that need a cast now checked through SPI" part is
not true as of now because I had assumed when writing it that I'd
commit the patch at [1] to make it true before this one but that
didn't happen. The fix itself isn't invalidated (it still accounts
for user actions in cast functions), but the description is
unfortunately incorrect at this moment.
--
Thanks, Amit Langote
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Amit Langote | 2026-10-08 03:50:46 | pgsql: Lock RI fast-path rows as of the scan snapshot's command ID |