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 60ce6b04f2e4049d04700730f1c439e325731dc4.camel@vmware.com
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2022-03-17 at 18:33 -0400, Tom Lane wrote:
> Yeah.  It seems to me that putting the auth info into struct Port was
> a fairly random thing to do in the first place, and we are now dealing
> with the fallout of that.
> 
> I think what we ought to do here is separate out the data that we think
> parallel workers need access to.  It does not seem wise to say "workers
> can access fields A,B,C of MyPort but not fields X,Y,Z".  I do not have
> a concrete proposal for fixing it though.

v6-0002 has my first attempt at this. I moved authn_id into its own
substruct inside Port, which gets serialized with the parallel key
machinery. (My name selection of "SharedPort" is pretty bland.)

Over time, we could move more fields into the shared struct and fill
out the serialization logic as needed, and then maybe eventually
SharedPort can be broken off into its own thing with its own
allocation. But I don't know if we should do it all at once, yet.

WDYT?

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Column Filtering in Logical Replication
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH] add relation and block-level filtering to pg_waldump