I wrote:
> I looked briefly at the idea of postponing ProcessStartupPacket
> until InitPostgres has set up a fairly normal environment. It
> seems like it'd take a fair amount of refactoring. I really
> doubt it's worth the effort, even though the result would be
> arguably cleaner logic than what we have now.
I felt more ambitious this morning and decided to take a harder look
at this idea. But I soon realized that there would be a concrete
disadvantage to delaying ProcessStartupPacket: until we have done that,
we don't have the correct value for FrontendProtocol so there is a
problem with reporting startup-time failures to the client. At least
some such failures, such as "too many clients already", are pretty
routine so we don't want to downgrade their user-friendliness.
If memory serves, libpq has some ability to cope with a v2 error message
even when it's expecting v3. But I wouldn't bet on that being true of
all client libraries, and anyway it's a very under-tested code path.
So I think we'd better go with the simple fix I showed before.
It's simple enough that maybe we could back-patch it, once it's
aged awhile in HEAD. OTOH, given the lack of field reports of
trouble here, I'm not sure back-patching is worth the risk.
regards, tom lane
