| 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
| 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 |