Re: PG19: two RI fast-path issues found while testing the batching revert

Hi Nik,

On Tue, Sep 15, 2026 at 11:14 AM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
>
> On Fri, Sep 11, 2026 at 2:25 AM Amit Langote
> <amitlangote09(at)gmail(dot)com> wrote:
> > For 0001, SPI's FOR KEY SHARE also requires UPDATE privilege on at
> > least one column. I've used ExecCheckOneRelPerms() to cover that along
> > with column-level SELECT. The tests exercise both per-row and batched
> > checks, including rejection without UPDATE and acceptance with UPDATE
> > on an unrelated column.
>
> I kept testing with my AI harness and found another case on master and
> PG19. Replacing a loose cross-type equality member leaves the FK's stored
> operator unchanged. An uncached fast-path check then errors; warmed
> metadata is not invalidated by the pg_amop change. The replacement calls
> the same int48eq function, so the family semantics are unchanged and SPI
> continues to enforce the FK normally.
>
> Attached are standalone fixes for master a625fc57 and PG19 f4b511ae.
> They invalidate the metadata on pg_amop changes and use SPI unless the
> stored operator is still an equality member. On master, buffered rows
> also need the SPI fallback if the family changes between AFTER triggers.
>
> Both assertion builds pass the native foreign_key test, full regression
> and isolation suites, and the injection-point suites. The tests cover
> warmed and uncached metadata and missing keys on both sides of the DDL.

Thanks for the report and the patch.

I've added an open item:

RI fastpath misses pg_amop updates
Commit: 2da86c1ef9b
Owner: Amit Langote

--
Thanks, Amit Langote