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: <110116.1599682140@sss.pgh.pa.us>
References: <1850884.1599601164@sss.pgh.pa.us>
 <20200909192620.dylomoxknmt6rdb3@alap3.anarazel.de>
 <110116.1599682140@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Wed, 09 Sep 2020 16:09:00 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <113529.1599684626.1@sss.pgh.pa.us>
Date: Wed, 09 Sep 2020 16:50:26 -0400
Message-ID: <113530.1599684626@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Not only DNS, but all the various auth libraries would have to be
> contended with.  Lots of work there compared to the likely rewards.

Wait a minute.  The entire authentication cycle happens inside
InitPostgres, using the backend's normal signal handlers.  So
maybe we are overthinking the problem.  What if we simply postpone
ProcessStartupPacket into that same place, and run it under the same
rules as we do for authentication?  We would waste more cycles than
we do now for the case where the client closes the connection without
sending a startup packet, but not enormously so, I think --- and
optimizing that case doesn't seem like a high-priority goal anyway.
And cases like DNS lookup taking forever don't seem like any more of
an issue than auth lookup taking forever.

			regards, tom lane