On Mon, May 17, 2010 at 4:33 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Sat, May 15, 2010 at 3:20 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Hmm, OK, I think that makes sense. Would you care to propose a patch?
>
> Yep. Here is the patch.
>
> This patch distinguishes normal shutdown from unexpected exit, while the
> server is in recovery. That is, when smart or fast shutdown is requested
> during recovery, the bgwriter sets the ControlFile->state to new-introduced
> DB_SHUTDOWNED_IN_RECOVERY state.
>
> When recovery starts from the DB_SHUTDOWNED_IN_RECOVERY state, the startup
> process emits
>
> LOG: database system was shut down in recovery at 2010-05-12 20:35:24 EDT
>
> instead of
>
> LOG: database system was interrupted while in recovery at log
> time 2010-05-12 20:35:24 EDT
> HINT: If this has occurred more than once some data might be
> corrupted and you might need to choose an earlier recovery target.
Heikki and I discussed this over IM today and came away with two questions.
First, is it appropriate to set the control file state to
DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as
opposed to archive recovery/SR)? My vote is no, but Heikki thought it
might be OK.
Second, one of the places where this patch updates the control file
immediately follows a call to UpdateMinRecoveryPoint(). That can lead
to fsync-ing the control file twice in a row. Should we worry about
this or just let it go?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company