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

From Michael Paquier
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id Yj6wU9DZ7c6MHfTb@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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? I guess I don't have any
> intuition on how that would compare to the separate-global-and-accessor
> approach. Is the primary advantage that you don't have to maintain the
> serialization logic, or is there more to it?

Hmm.  That would be a first for a GUC, no?  It is not seem natural
compared to the other information pieces passed down from the leader
to the workers.

+extern SharedPort MyProcShared;

This naming is interesting, and seems to be in line with a couple of
executor structures that share information across workers.  Still
that's a bit inconsistent as Shared is used once at the beginning and
once at the end?  I don't have a better idea on top of my mind.

Anyway, wouldn't it be better to reverse the patch order, introducing
the shared Proc information first and then build the parallel-safe
function on top of it?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Add LZ4 compression in pg_dump
Next
From: Julien Rouhaud
Date:
Subject: Re: make MaxBackends available in _PG_init