From: "Peter Eisentraut" <pete...@gmx.net>
On 1/30/13 9:11 AM, MauMau wrote:
When I ran "pg_ctl stop -mi" against the primary, some applications
connected to the primary did not stop. The cause was that the backends
was deadlocked in quickdie() with some call stack like the following.
I'm sorry to have left the stack trace file on the testing machine, so
I'll show you the precise stack trace tomorrow.
I've had similar problems in the past:
http://www.postgresql.org/message-id/1253704891.20834.8.ca...@fsopti579.f-secure.com
The discussion there never quite concluded. But yes, you need to be
prepared that in rare circumstances SIGQUIT won't succeed and you need
to use SIGKILL.
Thank you for sharing your experience. So you also considered making
postmaster SIGKILL children like me, didn't you? I bet most of people who
encounter this problem would feel like that.
It is definitely pg_ctl who needs to be prepared, not the users. It may not
be easy to find out postgres processes to SIGKILL if multiple instances are
running on the same host. Just doing "pkill postgres" will unexpectedly
terminate postgres of other instances.
I would like to make a patch which that changes SIGQUIT to SIGKILL when
postmaster terminates children. Any other better ideas?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
