Re: Superuser connect during smart shutdown

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Superuser connect during smart shutdown
Дата
Msg-id 79984128.833417.1427122922359.JavaMail.yahoo@mail.yahoo.com
обсуждение исходный текст
Ответ на Re: Superuser connect during smart shutdown  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: Superuser connect during smart shutdown  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> wrote:
> On 3/20/15 9:44 AM, Kevin Grittner wrote:
>> Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Thu, Mar 19, 2015 at 10:42 PM, Bruce Momjian <bruce@momjian.us> wrote:

>>>> OK, are we up for changing the default pg_ctl shutdown method
>>>> for 9.5, ("smart" to "fast"), [...]?
>>>
>>> I'm up for it. I think it's long overdue.
>>
>> +1
>
> +1, but I also like the idea of allowing SU to connect during a
> smart shutdown. Even if you've intentionally chosen smart
> instead of fast it still sucks that you can't find out what's
> actually holding things up (and ps isn't that great a solution).

I like that idea a lot, too.  Having been in the position of
remotely administering about 80 database servers, and getting a
call that the building containing one of them was on fire, and the
fire department would be arriving in two or three minutes to cut
power to the building and start spraying water on everything, I
found current behavior rather nervous-making as I struggled to get
a clean shutdown of PostgreSQL followed by a clean shutdown and
power-off of the server before that happened.  The ability to make
an SU connection during either "fast" or "smart" shutdown can be
useful in a world of connection pools and long-running report
queries.  And fires.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Display of multi-target-table Modify plan nodes in EXPLAIN
Следующее
От: Robert Haas
Дата:
Сообщение: Re: barnacle (running CLOBBER_CACHE_RECURSIVELY) seems stuck since November