Re: recovery getting interrupted is not so unusual as it used to be

On Mon, May 17, 2010 at 4:33 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, May 15, 2010 at 3:20 AM, Robert Haas <robertmhaas(at)gmail(dot)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