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

From Tom Lane
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id 973625.1647556418@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
Jacob Champion <pchampion@vmware.com> writes:
> On Fri, 2022-03-04 at 10:45 +0900, Michael Paquier wrote:
>> At the end of the day, Port is an interface used for the communication
>> between the postmaster with the frontends, so I'd like to say that it
>> is correct to not apply this concept to parallel workers because they
>> are not designed to contact any frontend-side things.

> Coming back to this late, sorry. I'm not quite sure where to move with
> this. I'm considering copying pieces of Port over just so we can see
> what it looks like in practice?

> Personally I think it makes sense for the parallel workers to have the
> authn information for the client -- in fact there's a lot of
> information that it seems shouldn't be hidden from them -- but there
> are other pieces, like the socket handle, that are clearly not useful.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ExecTypeSetColNames is fundamentally broken
Next
From: Nathan Bossart
Date:
Subject: Re: O(n) tasks cause lengthy startups and checkpoints