From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: SIGQUIT handling, redux
In-reply-to: <320251.1599792006@sss.pgh.pa.us>
References: <1850884.1599601164@sss.pgh.pa.us>
 <20200909192620.dylomoxknmt6rdb3@alap3.anarazel.de>
 <110116.1599682140@sss.pgh.pa.us> <113530.1599684626@sss.pgh.pa.us>
 <116384.1599688841@sss.pgh.pa.us> <141736.1599693895@sss.pgh.pa.us>
 <320251.1599792006@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 10 Sep 2020 22:40:06 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <394090.1599839575.1@sss.pgh.pa.us>
Date: Fri, 11 Sep 2020 11:52:55 -0400
Message-ID: <394091.1599839575@sss.pgh.pa.us>
Precedence: bulk

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