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
Дата
Msg-id 5644.1245964668@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Simon Riggs <simon@2ndQuadrant.com>)
Re: BUG #4879: bgwriter fails to fsync the file in recovery mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-bugs
Heikki Linnakangas <heikki.linnakangas@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.

            regards, tom lane

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

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