Horton

Re: SIGQUIT handling, redux

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-09-09T20:50:26Z
Lists: pgsql-hackers 
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

Commits

  1. Log a message when resorting to SIGKILL during shutdown/crash recovery.

  2. Don't run atexit callbacks during signal exits from ProcessStartupPacket.

  3. Use _exit(2) for SIGQUIT during ProcessStartupPacket, too.

  4. Make archiver's SIGQUIT handler exit via _exit().