Re: [RFC] Should we fix postmaster to avoid slow shutdown?

From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
> So there are two questions here:
>
> 1. Should we try to avoid having the stats collector write a stats file
> during an immediate shutdown? The file will be removed anyway during crash
> recovery, so writing it is pointless. I think you are right that 9.4's
> solution here is not perfect, because of the 5 second delay, and also because
> if the stats collector is stuck inside the kernel trying to write to the
> OS, it may be in a non-interruptible wait state where even SIGKILL has no
> immediate effect. Anyway, it's stupid even from a performance point of
> view to waste time writing a file that we're just going to nuke.
>
> 2. Should we close listen sockets sooner during an immediate shutdown?
> I agree with Tom and Peter that this isn't a good idea. People expect
> the sockets not to go away until the end - e.g. they use
> PQping() to test the server status, or they connect just to see what error
> they get - and the fact that a client application could hypothetically
> generate such a relentless stream of connection attempts that the dead-end
> backends thereby created slow down shutdown is not in my mind a sufficient
> reason to change the behavior.
>
> So I think 001 should proceed and 002 should be rejected.

I'm happy with this conclusion, since I think 1 was the cause of slow shutdown, and 2 is just a hypothesis to pursue the completeness. And I can understand the concern about PQping().

Regards
Takayuki Tsunakawa