From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, "Andres Freund" <andres(at)2ndquadrant(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks) |
Date: | 2013-06-22 02:02:46 |
Message-ID: | 7C0FBE1D27DD4DA8ABB2B3928902CB2D@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
On Thu, Jun 20, 2013 at 12:33 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | MauMau | 2013-06-22 02:30:04 | Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks) |
Previous Message | Martín Marqués | 2013-06-22 01:56:00 | problem with commitfest redirection |