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

Поиск
Список
Период
Сортировка
От MauMau
Тема Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)
Дата
Msg-id 7C0FBE1D27DD4DA8ABB2B3928902CB2D@maumau
обсуждение исходный текст
Ответ на Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Martín Marqués
Дата:
Сообщение: problem with commitfest redirection
Следующее
От: "MauMau"
Дата:
Сообщение: Re: backend hangs at immediate shutdown (Re: Back-branch update releases coming in a couple weeks)