"MauMau" <maumau307(at)gmail(dot)com> writes:
> When I ran "pg_ctl stop -mi" against the primary, some applications
> connected to the primary did not stop. ...
> The root cause is that gettext() is called in the signal handler quickdie()
> via errhint().
Yeah, it's a known hazard that quickdie() operates like that.
> I think the solution is the typical one. That is, to just remember the
> receipt of SIGQUIT by setting a global variable and call siglongjmp() in
> quickdie(), and perform tasks currently done in quickdie() when sigsetjmp()
> returns in PostgresMain().
I think this cure is considerably worse than the disease. As stated,
it's not a fix at all: longjmp'ing out of a signal handler is no better
defined than what happens now, in fact it's probably even less safe.
We could just set a flag and wait for the mainline code to notice,
but that would make SIGQUIT hardly any stronger than SIGTERM --- in
particular it couldn't get you out of any loop that wasn't checking for
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.
> What do think about the solution? Could you include the fix?
Even if we had an arguably-better solution, I'd be disinclined to
risk cramming it into stable branches on such short notice.
What might make sense on short notice is to strengthen the
documentation's cautions against using SIGQUIT unnecessarily.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Andres Freund||Date: 2013-01-30 15:34:53|
|Subject: Re: backend hangs at immediate shutdown (Re: Back-branch
update releases coming in a couple weeks)|
|Previous:||From: Hari Babu||Date: 2013-01-30 15:06:36|
|Subject: Re: Strange Windows problem, lock_timeout test request|