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

Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Tom Lane wrote:
>>> I would like an explanation of why minimum recovery point needs to
>>> be advanced at all. If there's any use for it, it is surely part
>>> of functionality that is not there in 8.4.
>
>> It gives protection against starting up the database too early.
>
> Protection against what failure scenario?
>
>> It stops
>> the database from starting up if you stop recovery, and move recovery
>> target backwards or delete WAL files from pg_xlog, in a way that's not
>> safe. Of course, that's a case of "don't do that!", but it's a mistake
>> you can make when trying to manually recover to a given point in time.
>
> You can't move the target backwards --- it's embedded in pg_control.

No it's not. It's in recovery.conf.

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.

> And even if you could, I don't see what protection this particular
> mechanism gives you. To the extent that it does anything at all, it's
> going to be full of holes because it only examines pages that happen to
> be dirtied by (the current instance of) the recovery process.

The only process dirtying pages during recovery is the startup process,
when it replays WAL. And for the sake of a consistent database if we
crash, we only care about pages that have been written to disk.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com