Re: [PATCH] Allow complex data for GUC extra.

On Mon, Dec 15, 2025 at 1:03 AM Bryan Green <dbryan.green@gmail.com> wrote:
> TLDR; There is a possibility of GUCs using contexts that do not reset;
> combined with a small window of opportunity this would lead to a leak
> given correct timing. We could accept the leak risk, only allow extra
> data as a context for PGC_USERSET and PGC_SUSET GUCs, create a new
> context that is global but resets, or look for a different solution.

I think the last two solutions are best.

One idea is to create a context, maybe a child of GUCMemoryContext,
that is the initial parent for all temporary check-hook contexts. When
the check-hook completes, the context is reparented to
GUCMemoryContext. At some appropriate point in the code, we delete any
leftover children of that context. "Some appropriate point in the
code" could mean "right before we create a new temporary check-hook
context" if it's the case that one check-hook can never be reached
from another check-hook, or it could be elsewhere if reentrancy is a
problem.

Another idea is to just keep track of which contexts need to be
deleted if we error out. Let's say that when we create a temporary
check-hook context, we add it to a linked list, similar to
guc_stack_list, but each element of the list is just a memory context
pointer and the current GUCNestLevel. When AtEOXact_GUC is called,
after doing the stuff it does today, it can iterate over this new list
and filter on nestLevel. Entries that need to get blown away are
subjected to MemoryContextDelete() and also deleted from the list.

--
Robert Haas
EDB: http://www.enterprisedb.com