"MauMau" <maumau307@gmail.com> writes:
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
>> The long and the short of it is that SIGQUIT is the emergency-stop panic
>> button. You don't use it for routine shutdowns --- you use it when
>> there is a damn good reason to and you're prepared to do some manual
>> cleanup if necessary.
> How about the case where some backend crashes due to a bug of PostgreSQL?
> In this case, postmaster sends SIGQUIT to all backends, too. The instance
> is expected to disappear cleanly and quickly. Doesn't the hanging backend
> harm the restart of the instance?
[ shrug... ] That isn't guaranteed, and never has been --- for
instance, the process might have SIGQUIT blocked, perhaps as a result
of third-party code we have no control over.
> How about using SIGKILL instead of SIGQUIT?
Because then we couldn't notify clients at all. One practical
disadvantage of that is that it would become quite hard to tell from
the outside which client session actually crashed, which is frequently
useful to know.
This isn't an area that admits of quick-fix solutions --- everything
we might do has disadvantages. Also, the lack of complaints to date
shows that the problem is not so large as to justify panic responses.
I'm not really inclined to mess around with a tradeoff that's been
working pretty well for a dozen years or more.
regards, tom lane
