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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Дата
Msg-id 4A43E53B.1030505@enterprisedb.com
обсуждение исходный текст
Ответ на Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #4879: bgwriter fails to fsync the file in recovery mode