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

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,
Nik