Re: [PATCH] Expose port->authn_id to extensions and triggers

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <pchampion@vmware.com>, "rjuju123@gmail.com" <rjuju123@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "sfrost@snowman.net" <sfrost@snowman.net>
Date: 2022-03-26T17:15:50Z
Lists: pgsql-hackers
Hi,

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?


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

What would be the first for a GUC? We have plenty GUCs that are set on a
per-connection basis to reflect some fact? And there's several authenitcation
related bits of state known to guc.c , think role, session_authorization,
is_superuser.

Sharing per-connection state via GUCs for paralellism? I don't think that is
true either. E.g. application_name, client_encoding.


> +extern SharedPort MyProcShared;

I strongly dislike MyProcShared. It's way too easily confused with MyProc
which point to shared memory.

Greetings,

Andres Freund



Commits

  1. Remove initialization of MyClientConnectionInfo at backend startup

  2. Allow parallel workers to retrieve some data from Port