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

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 www.2ndQuadrant.com
PostgreSQL Training, Services and Support