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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Allow complex data for GUC extra.
Дата
Msg-id 2547350.1765940693@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Allow complex data for GUC extra.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Dec 16, 2025 at 4:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... Therefore, there can be at most one of these
>> operations in flight at a time, so you don't need any dynamic data
>> structure.  A simple static variable remembering a not-yet-reparented
>> context would do it.

> Oh, yeah, I actually wondered if that would be an acceptable
> restriction and had it in an earlier version of the email, but it got
> lost in the final draft. Maybe with this design you just do something
> like:
> if (TempCheckHookConteck != NULL)
>      MemoryContextReset(TempCheckHookConteck);
> else
>      TempCheckHookConteck = AllocSetContextCreate(...);
> So then if the context survives, you just reset and reuse it, but if
> it gets reparented, you set the variable to NULL and create a new
> context the next time. Then you don't need any integration with
> (sub)transaction abort at all, which seems nice.

You could do it like that, but I'd prefer a setup that would give
an assertion failure if someone did try to invoke it recursively.
So I'd opt for allocation like

    Assert(TempCheckHookContext == NULL);
    TempCheckHookContext = AllocSetContextCreate(...);

and then you would need cleanup in AtEOXact_GUC, but that's
hardly complicated.

            regards, tom lane



В списке pgsql-hackers по дате отправления: