Re: Allow WAL information to recover corrupted pg_controldata

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Allow WAL information to recover corrupted pg_controldata
Дата
Msg-id CAHGQGwHcuKA6KJTKmbVX5ZOPJVhXD4Q9Mz__fbnTvybLjBb0tQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allow WAL information to recover corrupted pg_controldata  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Allow WAL information to recover corrupted pg_controldata  (Amit Kapila <amit.kapila@huawei.com>)
Список pgsql-hackers
On Wed, Jun 20, 2012 at 12:40 PM, Amit Kapila <amit.kapila@huawei.com> wrote:
>>> I believe if WAL files are proper as mentioned in Alvaro's mail, the
> purposed logic should generate
>>> correct values.
>>> Do you see any problem in logic purposed in my original mail.
>>> Can I resume my work on this feature?
>
>> Maybe I'm missing your point, but... why don't you just use PITR to
>> recover from the corruption of pg_control?
>
> AFAIK PITR can be used in a scenario where there is a base back-up and we
> have archived
> the WAL files after that, now it can use WAL files to apply on base-backup.

Yes. If you want to recover the database from the media crash like the
corruption of pg_control file, you basically should take a base backup
and set up continuous archiving.

> In this scenario we don't know a point from where to start the next replay.
> So I believe it will be difficult to use PITR in this scenario.

You can find out the point from the complete pg_control file which was
restored from the backup.

If pg_control is corrupted, we can easily imagine that other database files
would also be corrupted. I wonder how many cases where only pg_control
file gets corrupted are. In that case, pg_resetxlog is unhelpful at all.
You need to use PITR, intead.

Regards,

-- 
Fujii Masao


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: sortsupport for text
Следующее
От: David Fetter
Дата:
Сообщение: Re: Nasty, propagating POLA violation in COPY CSV HEADER