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
-
Remove initialization of MyClientConnectionInfo at backend startup
- 701ac2cb1fa2 16.0 landed
-
Allow parallel workers to retrieve some data from Port
- d951052a9e02 16.0 landed