Hi Nik, On Fri, Sep 11, 2026 at 1:02 AM Nikolay Samokhvalov <[email protected]> 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
