On Thu, May 7, 2026 at 6:09 PM Amit Langote <[email protected]> wrote: > On Wed, May 6, 2026 at 5:14 PM Anthonin Bonnefoy > <[email protected]> wrote: > > On Tue, May 5, 2026 at 8:38 AM Amul Sul <[email protected]> wrote: > > > Here is the reproducible test that has an AFTER INSERT trigger on a > > > referenced table that recursively inserts rows into itself: > > > > > > -- > > > create table trigger_recursive_pk (id int primary key); > > > create table trigger_recursive_fk (id int references > > > trigger_recursive_pk(id)); > > > insert into trigger_recursive_pk select g from generate_series(1, 15) g; > > > > > > create function trigger_recursive_fn() returns trigger language plpgsql > > > as $$ > > > begin > > > if new.id < 10 then > > > insert into trigger_recursive_fk values (new.id + 1); > > > end if; > > > return new; > > > end$$; > > > > > > create trigger trigger_recursive after insert on trigger_recursive_fk > > > for each row execute function trigger_recursive_fn(); > > > > > > insert into trigger_recursive_fk values (1); > > > -- > > > > I've managed to reproduce the issue on the current HEAD thanks to the > > script. Doing a git bissect, the failure was introduced with > > 34a30786293005 when the batch_callbacks list was added. > > > > > The attached patch fixes the reported issue by recomputing qs > > > immediately before calling FireAfterTriggerBatchCallbacks(). > > > > The patch fixes the issue and the change looks reasonable. > > Thanks for the review. I agree. > > Attached v2. I simplified the test because the FK isn't really needed > to reproduce the bug, since the use-after-free is the stale qs load > itself. Also reworded the comment above the recompute and tweaked the > commit message a bit. > > Will push tomorrow barring objections. Thanks again, Amul, for the patch.
Pushed. -- Thanks, Amit Langote
