Re: [PATCH] Allow complex data for GUC extra. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Allow complex data for GUC extra.
Date
Msg-id 2547350.1765940693@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Allow complex data for GUC extra.  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Change the signature of pgstat_report_vacuum() so that it's passed a Relation
Next
From: "cca5507"
Date:
Subject: Re: A small problem when rehashing catalog cache