On 2013-02-01 08:55:24 -0500, Peter Eisentraut wrote: > On 1/31/13 5:42 PM, MauMau wrote: > > 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. > > In my case, it was one backend process segfaulting, and then some other > backend processes didn't respond to the subsequent SIGQUIT sent out by > the postmaster. So pg_ctl didn't have any part in it. > > We ended up addressing that by installing a nagios event handler that > checked for this situation and cleaned it up. > > > I would like to make a patch which that changes SIGQUIT to SIGKILL when > > postmaster terminates children. Any other better ideas? > > That was my idea back then, but there were some concerns about it. > > I found an old patch that I had prepared for this, which I have > attached. YMMV.
> +static void > +quickdie_alarm_handler(SIGNAL_ARGS) > +{ > + /* > + * We got here if ereport() was blocking, so don't go there again > + * except when really asked for. > + */ > + elog(DEBUG5, "quickdie aborted by alarm"); > + Its probably not wise to enter elog.c again, that path might allocate memory and we wouldn't be any wiser. Unfortunately there's not much besides a write(2) to stderr that can safely be done... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers