Re: PG19 FK fast path: OOB write and missed FK checks during batched

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

In response to

Browse pgsql-hackers by date

  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