On Thu, 2009-06-25 at 17:17 -0400, Tom Lane wrote: > Heikki Linnakangas <heikki.linnakan...@enterprisedb.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
