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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bryan Green <dbryan(dot)green(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Allow complex data for GUC extra.
Date: 2025-12-17 01:38:01
Message-ID: CA+TgmobH-BGhEccHyzCwrEe3z783E0n5=ay3k5hzMBZrrBZGKg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 16, 2025 at 4:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alternatively: I don't see any really good reason for a check_hook
> to be setting other GUCs, in fact it's probably a seriously bad idea.
> (It's a *check* hook, it's not supposed to be causing any
> side-effects.) 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-12-17 01:57:14 Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers
Previous Message Euler Taveira 2025-12-17 00:10:33 Re: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions