Re: pending patch: Re: HS/SR and smart shutdown
От | Robert Haas |
---|---|
Тема | Re: pending patch: Re: HS/SR and smart shutdown |
Дата | |
Msg-id | y2y603c8f071004130627o56b9c836x8254ff0c0a59f579@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pending patch: Re: HS/SR and smart shutdown (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: pending patch: Re: HS/SR and smart shutdown
|
Список | pgsql-hackers |
On Tue, Apr 13, 2010 at 9:18 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Thu, Apr 1, 2010 at 8:24 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Apr 1, 2010 at 7:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> I'm not willing to investigate this further myself at this stage. This >>> looks like risk for little benefit. >> >> That's kind of what I figured. I'll see about fixing up Fujii-san's >> patch and documenting the behavior; but it won't happen before the >> weekend because I'm going to be out of town. > > I found the bug which makes smart shutdown get stuck for a while: > > If there is no WAL file available in the standby, walreceiver might > be invoked before we have reached the PM_RECOVERY state. We switch > to the PM_RECOVERY state after reading the checkpoint record pointed > out in the pg_control file. If it's not found, we are in the PM_INIT > or PM_START state and start walreceiver to read it from the primary. > > If smart shutdown is requested at that point, we cannot switch to > the PM_WAIT_READONLY state because pmdie() doesn't allow that. So > the SIGTERM is never sent to walreceiver, and smart shutdown would > get stuck. > > If the current state is either PM_INIT or PM_START, it's guaranteed > that there is no regular backend, so we should kill walreceiver as > soon as smart shutdown is requested, I think. The attached patch > does that. Can you explain how to recreate the problem that this patch fixes? ...Robert
В списке pgsql-hackers по дате отправления: