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

From Jacob Champion
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id 94c53220cb1e8a7a9c411fd14bfc64ff3b65d68d.camel@vmware.com
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  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
> On 2022-03-23 23:06:14 +0000, Jacob Champion wrote:
> > On Wed, 2022-03-23 at 19:00 -0400, Tom Lane wrote:
> > > Hm.  I was more envisioning getting the "sharable" info out of Port
> > > entirely, although I'm not quite sure where it should go instead.
> > 
> > If it helps, I can move the substruct out and up to a new global struct
> > (MyProcShared?). At this point I think it's mostly search-and-replace.
> 
> Perhaps alongside CurrentUserId etc in miscinit.c?  It would be nicer if all
> those were together in a struct, but oh well.

Next draft in v7. My naming choices probably make even less sense now. Any ideas for names for "a bag of stuff that we
wantparallel workers to have too"?
 

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

Thanks,
--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Documenting when to retry on serialization failure
Next
From: Zheng Li
Date:
Subject: Re: Support logical replication of DDLs