Re: pending patch: Re: HS/SR and smart shutdown
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2010-04-13T13:18:25Z
Lists: pgsql-hackers
Attachments
- smart_shutdown_bugfix_v1.patch (application/octet-stream) patch v1
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. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center