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

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Дата
Msg-id 0A3221C70F24FB45833433255569204D1F63BF1C@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: [RFC] Should we fix postmaster to avoid slow shutdown?  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Список pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Ashutosh Bapat
> I am not sure if following condition is a good idea in ServerLoop()
> 1650         if (pmState == PM_WAIT_DEAD_END || ClosedSockets)
> 
> There are no sockets to listen on, so select in the else condition is going
> to sleep for timeout determined based on the sequence expected.
> Just before we close sockets in pmdie() it sets AbortStartTime, which
> determines the timeout for the sleep here. So, it doesn't make sense to
> ignore it. Instead may be we should change the default 60s sleep to 100ms
> sleep in DetermineSleepTime().

That sounds better.  I modified cleaned ServerLoop() by pushing the existing 100ms logic into DetermineSleepTime().


> While the postmaster is terminating children, a new connection request may
> arrive. We should probably close listening sockets before terminating
> children in pmdie().

I moved ClosePostmasterSocket() call before terminating children in the immediate shutdown case.  I didn't change the
behaviorof smart and fast shutdown modes, because they may take a long time to complete due to checkpointing etc.
Userswill want to know what's happening during shutdown or after pg_ctl stop times out, by getting the message "FATAL:
thedatabase system is shutting down" when they try to connect to the database.  The immediate shutdown or crash should
betterbe as fast as possible.
 


> Otherwise this patch looks good to me. It applies and compiles cleanly.
> make check-world doesn't show any failures.

Thank you for reviewing and testing.  The revised patch is attached.

Regards
Takayuki Tsunakawa


Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Let's get rid of SPI_push/SPI_pop
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows