On Mon, May 17, 2010 at 4:33 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Sat, May 15, 2010 at 3:20 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
