Re: [PATCH] Expose port->authn_id to extensions and triggers
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Дата | |
Msg-id | 20220326171550.ywohmkvngh4qc2fo@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Expose port->authn_id to extensions and triggers (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [PATCH] Expose port->authn_id to extensions and triggers
|
Список | 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
В списке pgsql-hackers по дате отправления: