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

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, kristianlejao(at)gmail(dot)com
Subject: Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c
Date: 2025-09-28 08:55:45
Message-ID: CAPmGK14FU6y2MA8ZuXBKiPnm1sw5SQq720BuRv_2YaTfQqow3Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Sep 26, 2025 at 10:34 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> On 2025-Sep-24, Etsuro Fujita wrote:
>
> > I took a quick glance at the patch. My initial comment is: it only
> > includes the test case discussed here, but I think it's a good idea to
> > add more cases in it (that exercise code paths in
> > postgresRecheckForeignScan), as I mentioned upthread. What do you
> > think about that? If no objections, I'd like to update it to include
> > such cases.
>
> I would like to suggest a different approach: because this patch is
> known to fix a server crash in a known case, it would be better to get
> the fix (and its corresponding test) pushed as is without further delay.
> Additional tests are an excellent idea, but I think we shouldn't make
> this patch wait for them. If further fixes are deemed necessary for
> those other (thus far hypothetical) tests, we can still make them
> afterwards.

The 2-step approach sounds reasonable, so I'll review the proposed
isolation test and report the results first.

Thanks!

Best regards,
Etsuro Fujita

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2025-09-28 23:47:52 Re: BUG #19062: PostgreSQL 12.22 does not compile because of conflicting types for CollationCreate
Previous Message David Rowley 2025-09-27 09:07:15 Re: BUG #19067: On master at commit 66cdef4425f3, "psql -c 'select 1' dbname" causes the backend to seg fault