On Thu, May 7, 2026 at 6:09 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Wed, May 6, 2026 at 5:14 PM Anthonin Bonnefoy
> <anthonin.bonnefoy@datadoghq.com> wrote:
> > On Tue, May 5, 2026 at 8:38 AM Amul Sul <sulamul@gmail.com> 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
