Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c - Mailing list pgsql-bugs

On Wed, Sep 17, 2025 at 5:25 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Sep 17, 2025 at 07:42:36PM +0900, Etsuro Fujita wrote:
> > The test case you showed upthread and added to the patch is useful, so
> > I think we should add it as well, but my question about it is: is it
> > really a good idea to use injection points?
>
> > Why don't you just use BEGIN/COMMIT statements like this:
> >
> > -- session 1
> > begin isolation level read committed;
> > update a set i = i + 1;
> >
> > -- session 2
> > begin isolation level read committed;
> > select a.i,
> >        (select 1 from b, c where a.i = b.i and b.i = c.i)
> > from a
> > for update; -- waits for the transaction in session 1 to complete
> >
> > -- session 1
> > commit;
> >
> > -- session 2
> > select a.i,
> >        (select 1 from b, c where a.i = b.i and b.i = c.i)
> > from a
> > for update; -- produces results after doing an EvalPlanQual recheck
> >  i | ?column?
> > ---+----------
> >  2 |
> > (1 row)
> >
> > Again, my apologies for the late response.
>
> As far as I can see, this causes the SELECT FOR UPDATE of session 2
> that's waiting for the commit of session 1 to crash, if we don't have
> the fix, of course.  Removing the dependency with injection points is
> nice if we don't require it, so we can just tweak the isolation test
> proposed upthread to use the same schema, but the queries you are
> suggesting.

+1

I changed the regression tests and used the fix proposed by
Fujita-san. Please review the attached new version patch.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com