Re: Revert RI fast-path batching from REL_19_STABLE

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, rmt(at)lists(dot)postgresql(dot)org
Subject: Re: Revert RI fast-path batching from REL_19_STABLE
Date: 2026-09-10 06:20:32
Message-ID: CA+HiwqG5z0PwVAzHaf02Web_h5xjze2VWJOFzGbJmdfgjmFAMA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 10, 2026 at 12:57 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Sep 9, 2026 at 9:12 PM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> >
> > On Wed, Sep 9, 2026 at 8:26 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > >
> > > That still leaves your concern about whether the per-row path is
> > > sufficiently solid for v19. The snapshot fixes and Amit's recent
> > > collation report show that there are differences from SPI that we (I)
> > > missed. The proposed collation fix falls back to SPI when the
> > > referenced index and column collations differ. I still propose
> > > retaining the per-row path, but agree that its readiness needs to be
> > > assessed separately from the decision to remove batching.
> >
> > I think a good start would be to revert the batching ASAP so that we
> > can consider the state after independently.
>
> BTW, it is not clear to me from this response whether it should be
> reverted for both 19 and 20 or just 19? I feel the reason to keep in
> 20 could be that it needs some (known) adjustments/bug-fixes and more
> testing but if there are still larger design issues, it will be better
> to revert even from 20. I was planning to evaluate that part but that
> needs more time, so it is better to first revert batching from 19, fix
> some reported issues for per-row optimization and evaluate whether it
> has any serious issues and make a decision based on that. Then
> independently, we can evaluate the batching state for 20 and take a
> call.

I have now reverted batching in REL_19_STABLE after pushing the
snapshot fix for the per-row path to master and REL_19_STABLE. and .
Batching remains in master for now.

With that, I've marked the following open items as fixed:

#1 RI fast-path batching fails during nested SET CONSTRAINTS
#2 RI fast-path batching wrongly used by ALTER TABLE inside a trigger
#3 Stale snapshot in RI fast-path leads to spurious failure

The fixes for #1 and #2 still need to be applied to master. Those
patches are posted at [1].

Later today, I will push the attached patches addressing Amit's review
in this thread to both branches. 0001 clarifies the tuple-lock result
handling comments. 0002 fixes the collation mismatch by falling back
to SPI. There are separate versions of 0002 for REL_19_STABLE, with
batching removed, and master, where both the per-row and batched paths
need the fallback.

--
Thanks, Amit Langote

[1] https://www.postgresql.org/message-id/CA%2BHiwqFxPkyD%2BtaMq7ENDqEfcY6xC_b1OAC-2d1wnfVyiXDY%3DQ%40mail.gmail.com

Attachment Content-Type Size
master-v6-0002-Fall-back-to-SPI-for-RI-checks-with-mismatched-in.patch application/octet-stream 21.0 KB
v6-0001-Clarify-RI-tuple-lock-result-handling-comments.patch application/octet-stream 2.0 KB
REL_19_STABLE-v6-0002-Fall-back-to-SPI-for-RI-checks-with-mismatched-in.patch application/octet-stream 13.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-09-10 06:21:27 Re: REPACK (CONCURRENTLY) decoding worker is canceled by lock_timeout
Previous Message vignesh C 2026-09-10 06:19:40 Re: Review items for EXCEPT TABLE publication