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