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)
|
Список | 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 по дате отправления: