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
