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

MauMau <maumau307@gmail.com>

From: "MauMau" <maumau307@gmail.com>
To: "Robert Haas" <robertmhaas@gmail.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Alvaro Herrera" <alvherre@2ndquadrant.com>, "Andres Freund" <andres@2ndquadrant.com>, "Peter Eisentraut" <peter_e@gmx.net>, <pgsql-hackers@postgresql.org>
Date: 2013-06-22T02:02:46Z
Lists: 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



Commits

  1. Consistency check should compare last record replayed, not last record read.

  2. Update minimum recovery point on truncation.