Re: Revert RI fast-path batching from REL_19_STABLE

On Thu, Sep 10, 2026 at 5:58 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> On Thu, Sep 10, 2026 at 3:20 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > 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.
>
> I've pushed 0001. I'm holding off on 0002 until tomorrow to give Amit
> some time to comment if he wants to.

I've pushed 0002 to master and REL_19_STABLE.

I'm also working on the two issues Nikolay Samokhvalov reported at
[1]. Both affect the per-row path, although the cast-cache bug
predates it. I aim to have these fixed by Monday.

I'll also push the patches for the batching issues mentioned upthread
to master on Monday so we can assess batching with those fixes
included.

--
Thanks, Amit Langote

[1] https://www.postgresql.org/message-id/CAM527d9BgPjeOOYmbCBTd57R145qHCk-dzw9qNq%2BnOrDq1j__A%40mail.gmail.com