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

From MauMau
Subject Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
Date
Msg-id 7C0FBE1D27DD4DA8ABB2B3928902CB2D@maumau
Whole thread Raw
In response to Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
List pgsql-hackers
From: "Robert Haas" <robertmhaas@gmail.com>On Thu, Jun 20, 2013 at 12:33 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> I will go with 5 seconds, then.
>
> I'm uncomfortable with this whole concept, and particularly with such
> a short timeout.  On a very busy system, things can take a LOT longer
> than they think we should; it can take 30 seconds or more just to get
> a prompt back from a shell command.  5 seconds is the blink of an eye.

I'm comfortable with 5 seconds.  We are talking about the interval between 
sending SIGQUIT to the children and then sending SIGKILL to them.  In most 
situations, the backends should terminate immediately.  However, as I said a 
few months ago, ereport() call in quickdie() can deadlock indefinitely. 
This is a PostgreSQL's bug.  In addition, Tom san was concerned that some 
PLs (PL/Perl or PL/Python?) block SIGQUIT while executing the UDF, so they 
may not be able to respond to the immediate shutdown request.

What DBAs want from "pg_ctl stop -mi" is to shutdown the database server as 
immediately as possible.  So I think 5 second is reasonable.

Regards
MauMau




pgsql-hackers by date:

Previous
From: Martín Marqués
Date:
Subject: problem with commitfest redirection
Next
From: "MauMau"
Date:
Subject: Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)