Re: Postgres fdw: Bug in InitPgFdwOptions initialization can cause an esoteric crash

From: Lucas Jeffrey <luquijeffrey(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, etsuro(dot)fujita(at)gmail(dot)com
Subject: Re: Postgres fdw: Bug in InitPgFdwOptions initialization can cause an esoteric crash
Date: 2026-11-09 15:20:22
Message-ID: CAObkL7N8BqFWgYrwMh7H7wpHFgP9vnC21K3sX+YXi8UG3aSO2w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi fujii,
Yes, I checked `0f9d4d7c12d`, and I agree it introduced the issue.

The global pointer was already being assigned before the array was
fully initialized,
but previously there was no operation in the initialization loop that
could generate an exception (OOM).

This commit started using MemoryContextStrdup() to copy each keyword,
which can raise an ERROR. If that happens,
`postgres_fdw_options` has already been assigned and remains non-NULL,
even though the initialization is incomplete.

So the initialization order was already there, but this commit made it
unsafe by introducing a possible ERROR in the middle of the
initialization.
Backpatching the fix to REL_19_STABLE makes sense to me.

Regards,
Lucas Jeffrey

On Mon, Nov 9, 2026 at 4:56 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Mon, Nov 9, 2026 at 6:51 AM Lucas Jeffrey <luquijeffrey(at)gmail(dot)com> wrote:
> > I created a v0 of a patch to solve this issue
>
> Thanks for the report and patch! LGTM.
>
> This issue was introduced by 0f9d4d7c12d, right? If so, we should backpatch
> the fix to v19, where that commit was introduced, even though this issue
> seems unlikely to occur in practice?
>
> Regards,
>
> --
> Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Geier 2026-11-09 15:31:31 Re: Reduce build times of pg_trgm GIN indexes
Previous Message Tom Lane 2026-11-09 15:20:06 Re: Draft back-branch release notes are up