| From: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com> |
| Subject: | Re: PG19 FK fast path: OOB write and missed FK checks during batched |
| Date: | 2026-09-15 02:11:55 |
| Message-ID: | CAM527d9ob0Sp4eXgtutnUC7pP+JG5wxfhLjYx1OqvfDDe31kzQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 9, 2026 at 4:37 AM Amit Langote
<amitlangote09(at)gmail(dot)com> wrote:
> The resource-owner handling turned out simpler than I expected: because
> AtEOSubXact_RI() runs after the subtransaction's ResourceOwnerRelease(),
> it only forgets the aborting level's cache entries and never closes their
> relations itself, so a batch flush that errors partway through inside a
> subxact is cleaned up by the ResourceOwner on the way out.
I kept testing this with my AI harness and found one remaining issue.
The ResourceOwner releases the relations, but the slots and flush context
live in TopTransactionContext. After 1,000 caught FK violations in one
transaction, master retains 1,000 contexts (16 MB) until transaction end.
Attached fixes it by releasing the entry before ResourceOwner cleanup,
using the owner that acquired its references. It also records the owner
and subtransaction before initialization can fail. The regression test
covers a PL/pgSQL exception block and an explicit savepoint.
Tested on master ceae3099: regression, isolation and injection-point
suites pass. The patch applies to current master a625fc5. PG19 no longer
has this batching code.
Thanks,
Nik
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Release-RI-fast-path-entry-resources-on-subtransaction-abort.patch | application/x-patch | 11.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikolay Samokhvalov | 2026-09-15 02:12:30 | [PATCH] Invalidate cached plans when casts change |
| Previous Message | Nikolay Samokhvalov | 2026-09-15 01:31:47 | Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start |