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