Re: [PATCH] Expose port->authn_id to extensions and triggers

On Thu, Mar 03, 2022 at 07:16:17PM +0000, Jacob Champion wrote:
> I guess it depends on what we want MyProcPort to look like in a
> parallel worker. Are we comfortable having most of it be blank/useless?
> Does it need to be filled in?

Good question.  It depends on the definition of how much
authentication information makes sense for the parallel workers to
inherit from the parent.  And as I mentioned upthread, this definition
is not completely clear to me because the parallel workers do *not* go
through the authentication paths of the parent, they are just spawned
in their own dedicated paths that the leader invokes.  Inheriting all
this information from the leader has also an impact on the
PgBackendStatus entries of the workers as these are reported in
pg_stat_activity as far as I recall, and it could be confusing to see,
for example, some SSL or some GSS information for automatically
spawned processes because these don't use SSL or GSS when they pass
back data to the leader.

I have been looking at the commit history, and found about 6b7d11f
that switched all the functions of sslinfo to be parallel-restricted
especially because of this.  So if we inherit all this information the
restriction on the sslinfo functions could be lifted, though the
interest is honestly limited in this case.

postgres_fdw has introduced recently the concept of cached
connections, as of v14 with 411ae64 and 708d165, with a set of
parallel-restricted functions.  Some of the code paths related to
appname look at MyProcPort, so there could be a risk of having some
inconsistent information if this is accessed in a parallel worker.
Looking at the code, I don't think that it would happen now but
copying some of the data of MyProcPort to the worker could avoid any
future issues if this code gets extended.

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.
--
Michael