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
-
Consistency check should compare last record replayed, not last record read.
- 970fb12de121 9.3.0 cited
-
Update minimum recovery point on truncation.
- 7bffc9b7bf9e 9.3.0 cited