| 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
| 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 |