Skip site navigation (1) Skip section navigation (2)

Re: BUG #4879: bgwriter fails to fsync the file in recoverymode

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode
Date: 2009-06-25 21:46:31
Message-ID: 1245966391.4038.256.camel@ebony.2ndQuadrant (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Thu, 2009-06-25 at 17:17 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> > We do store the minimum recovery point required by the base backup in
> > control file, but it's not advanced once the recovery starts. So if you
> > start recovery, starting from say 123, let it progress to location 456,
> > kill recovery and start it again, but only let it go up to 300, you end
> > up with a corrupt database.
> I don't believe that you have the ability to do that.  Once the recovery
> process is launched, the user does not have the ability to control where
> the WAL scan proceeds from.  Or at least that's how it used to work, and
> if someone has tried to change it, it's broken for exactly this reason.
> The behavior you seem to have in mind would be completely disastrous
> from a performance standpoint, as we'd be writing and fsyncing
> pg_control constantly during a recovery.  I wouldn't consider that a
> good idea from a reliability standpoint either --- the more writes to
> pg_control, the more risk of fatal corruption of that file.
> This is sounding more and more like something that needs to be reverted.

AFAICS the problem Heikki is worried about exists 8.2+. If you stop
recovery, edit recovery.conf to an earlier recovery target and then
re-run recovery then it is possible that data that would not exist until
after the (new) recovery point has made its way to disk. The code in 8.4
does a few things to improve that but the base problem persists and
revoking code won't change that. We should describe the issue in the
docs and leave it at that - there is no particular reason to believe
anybody would want to do such a thing. 

 Simon Riggs 
 PostgreSQL Training, Services and Support

In response to


pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2009-06-25 21:53:36
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Previous:From: Simon RiggsDate: 2009-06-25 21:39:21
Subject: Re: BUG #4879: bgwriter fails to fsync the file in recoverymode

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group