Re: [RFC] Should we fix postmaster to avoid slow shutdown?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Дата
Msg-id 1416.1479760254@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [RFC] Should we fix postmaster to avoid slow shutdown?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 1. Should we try to avoid having the stats collector write a stats
> file during an immediate shutdown?  The file will be removed anyway
> during crash recovery, so writing it is pointless.

The point I was trying to make is that I think the forced-removal behavior
is not desirable, and therefore committing a patch that makes it be graven
in stone is not desirable either.

The larger picture here is that Takayuki-san wants us to commit a patch
based on a customer's objection to 9.2's behavior, without any real
evidence that the 9.4 change isn't a sufficient solution.  I've got
absolutely zero sympathy for that "the stats collector might be stuck in
an unkillable state" argument --- where's the evidence that the stats
collector is any more prone to that than any other postmaster child?
And for that matter, if we are stuck because of a nonresponding NFS
server, how is a quicker postmaster exit going to help anything?
You're not going to be able to start a new postmaster if the data
directory is on a nonresponsive server.

I'd be willing to entertain a proposal to make the 5-second limit
adjustable, but I don't think we need entirely new behavior here.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Postgres abort found in 9.3.11
Следующее
От: Joe Conway
Дата:
Сообщение: Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.