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

Hi Nik,

On Fri, Sep 11, 2026 at 1:02 AM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
>
> Hi hackers,
>
> After talking to Andrey Borodin yesterday, we thought it would be
> useful to check for remaining issues after the RI batching revert. I
> used the harness I'm building for general testing of new Postgres
> features. It found no issues caused by the revert itself, but found
> these two apparently pre-existing bugs that I think should be fixed.
>
> I haven't had time to verify the findings myself or fully read the
> output. This is the first time I'm sending a report without doing
> that. I still think it's useful given the circumstances, and my
> confidence is fairly high: the harness is designed to look for false
> positives and try to refute its findings.

Thanks for doing this.

> Both reproducers were run against compiled REL_19_STABLE at
> 5dec175fb4, with and without the v5 batching-removal series.
>
> Column-level SELECT rejected by the FK fast path
>
> Run as superuser:
>
> begin;
> create role fk_owner;
> create schema fk_test authorization fk_owner;
> set role fk_owner;
> set search_path = fk_test, pg_catalog;
>
> create table p (id int primary key, payload text);
> insert into p values (1, 'x');
> create table f (id int references p);
>
> revoke select on p from fk_owner;
> grant select (id) on p to fk_owner;
>
> select 1 from p where id = 1 for key share; -- succeeds
> insert into f values (1);
> -- ERROR: permission denied for table p
> rollback;
>
> The referenced-table owner has SELECT on the key column. The
> partitioned-parent SPI path accepts the same grants, but
> ri_CheckPermissions() checks only table-level SELECT.
>
> FK insert uses a dropped cast function
>
> Run in one session:
>
> begin;
> create schema cast_test;
> set local search_path = cast_test, pg_catalog;
>
> create type k as (v int);
> create function cast1(k) returns int
> language sql immutable strict as 'select $1.v';
> create cast (k as int) with function cast1(k) as implicit;
>
> create table p (id int primary key);
> create table f (id k references p);
> insert into p values (1);
> insert into f values (row(1)::k);
>
> drop cast (k as int);
> create function cast2(k) returns int
> language sql immutable strict as 'select $1.v';
> create cast (k as int) with function cast2(k) as implicit;
> drop function cast1(k);
>
> select row(1)::k::int; -- returns 1
> insert into f values (row(1)::k);
> -- ERROR: cache lookup failed for function <old cast1 OID>
> rollback;
>
> Both cast functions have identical behavior, and the DDL succeeds
> without cascade. Looks like the RI cast cache isn't invalidated.

Looking at these now. The first issue is clearly a fast-path code
problem. The 2nd one interacts with the existing non-fast-path code so
I'll need to check if the bug predates fast-path.

--
Thanks, Amit Langote