Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
Date
Msg-id 14201.1359731548@sss.pgh.pa.us
Whole thread Raw
In response to Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)  ("MauMau" <maumau307@gmail.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-02-01 08:55:24 -0500, Peter Eisentraut wrote:
>> 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...

Another objection to this is it still doesn't fix the case where the
process has blocked SIGQUIT.  My faith that libperl, libR, etc will
never do that is nil.

I think if we want something that's actually trustworthy, the
wait-and-then-kill logic has to be in the postmaster.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] HOT on tables with oid indexes broken
Next
From: Alvaro Herrera
Date:
Subject: Re: autovacuum not prioritising for-wraparound tables