On Fri, Jun 3, 2022 at 10:04 AM Tom Lane <t...@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
