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 <[email protected]> wrote: > > On Mon, Nov 9, 2026 at 6:51 AM Lucas Jeffrey <[email protected]> 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
