Horton

Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, kristianlejao@gmail.com
Date: 2025-09-18T00:24:49Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch.

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.

As a whole, +1 for your suggestion.
--
Michael