Re: [PATCH] Expose port->authn_id to extensions and triggers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id 88926.1648317459@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Andres Freund <andres@anarazel.de>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-03-26 15:18:59 +0900, Michael Paquier wrote:
>> On Thu, Mar 24, 2022 at 05:44:06PM +0000, Jacob Champion wrote:
>>> On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
>>>> Another option would be to make it a GUC. With a bit of care it could be
>>>> automatically synced by the existing parallelism infrastructure...

>>> Like a write-once, PGC_INTERNAL setting?

> Perhaps PGC_INTERNAL, perhaps PGC_SU_BACKEND, set with PGC_S_OVERRIDE?

Seems like making it a GUC does nothing to fix the complaint you had about
passing data to workers whether it's needed or not.  Sure, we don't then
need to write any new code for it, but it's still new cycles.  And it's
new cycles all throughout guc.c, too, not just in parallel worker start.

I also note that exposing it as a GUC means we have zero control over
who/what can read it.  Maybe that's not a problem, but it needs to be
thought about before we go down that path.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Remove an unused function GetWalRcvWriteRecPtr
Next
From: Andres Freund
Date:
Subject: Re: Pointer subtraction with a null pointer