On Fri, Jun 3, 2022 at 10:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I agree with Robert's complaint that Parallel is far too generic
> a term here. Also, the fact that this data is currently in struct
> Port seems like an artifact.
Why do we call this thing a Port, anyway?
I think I'd feel more comfortable here if we were defining what went
into which struct on some semantic basis rather than being like, OK,
so all the stuff we want to serialize goes into struct #1, and the
stuff we don't want to serialize goes into struct #2. I suppose if
it's just based on whether or not we want to serialize it, then the
placement of future additions will just be based on how people happen
to feel about the thing they're adding right at that moment, and there
won't be any consistency.
One could imagine dividing the Port struct into a couple of different
structs, e.g.
AuthenticationState: stuff that is needed only during authentication
and can be discarded thereafter (e.g. the HBA line, at least if the
comment is to be believed)
ClientCommunicationState: stuff that is used to communicate with the
client but doesn't need to be or can't be shared (e.g. the SSL object
itself)
ClientConnectionInfo: stuff that someone might want to look at for
information purposes at any time (e.g. authn_id, apparently)
Then we could serialize the third of these, keep the second around but
not serialize it, and free the first once connection setup is
complete.
--
Robert Haas
EDB: http://www.enterprisedb.com
