Re: [PATCH] Allow complex data for GUC extra.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bryan Green <dbryan.green@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-12-17T03:04:53Z
Lists: 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