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

From Etsuro Fujita
Subject Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c
Date
Msg-id CAPmGK16fkr0QhnV0dvX_car_tx9fe2JGTyWpH3zG0N41w-vqVQ@mail.gmail.com
Whole thread Raw
In response to Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-bugs
On Fri, Oct 3, 2025 at 7:21 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> I've updated the patch based on your comments. Please find the attached patch.

Thanks for updating the patch!

+step "s1_tuplock" {
+    EXPLAIN (COSTS OFF, ANALYZE ON, TIMING OFF, SUMMARY OFF, BUFFERS OFF)
+    SELECT a.i,
+       (SELECT 1 FROM fb, fc WHERE a.i = fb.i AND fb.i = fc.i)
+    FROM a as a
+    FOR UPDATE;
+}

Maybe my comment about this step was not enough, but I'm wondering we
should run EXPLAIN and then SELECT here like below, rather than
running EXPLAIN ANALYZE, as that seems more usual to me:

step "s1_tuplock" {
    EXPLAIN (VERBOSE, COSTS OFF)
    SELECT a.i,
       (SELECT 1 FROM fb, fc WHERE a.i = fb.i AND fb.i = fc.i)
    FROM a
    FOR UPDATE;
    SELECT a.i,
       (SELECT 1 FROM fb, fc WHERE a.i = fb.i AND fb.i = fc.i)
    FROM a
    FOR UPDATE;
}

I added the VERBOSE option to show the remote query, and removed the
alias for a.

BTW: you added quotation marks around a name for each session or step
like "s1_tuplock".  Do we really need them?  This is nitpicking,
though.

Best regards,
Etsuro Fujita



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #19071: commit b448f1c8d broke LEFT JOIN pushdown
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #11500: PRIMARY KEY index not being used