On Mon, Dec 15, 2025 at 1:03 AM Bryan Green <[email protected]> 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
