Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
kristianlejao@gmail.com
Date: 2025-09-23T21:41:45Z
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 →
-
Fix EvalPlanQual handling of foreign/custom joins in ExecScanFetch.
- 24e74b9621e4 14.20 landed
- 12b0c0e51b2f 13.23 landed
- 4a08603a2322 15.15 landed
- 5a9af48689dc 16.11 landed
- 2bb84ea7ef89 17.7 landed
- b14144325984 18.1 landed
- 12609fbacb00 19 (unreleased) landed
Attachments
- v3-0001-Fix-assertion-failure-in-postgresGetForeignJoinPa.patch (application/octet-stream) patch v3-0001
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