Simon Riggs wrote:
> 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.
The way I've bumped into that is when playing with pg_standby:
1. Create base backup, set up standby
2. Let pg_standby catch up, so that it waits for the next segment to arrive.
3. killall -9 postmaster
4. Start standby again
5. Create trigger file, before recovery catches up again (that is,
before it reaches the point where it was before killing it)
Now that we have the "smart" mode in pg_standby, that's harder to do by
accident, but can still happen if you e.g remove a WAL file from archive.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
