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
|
Список | 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 по дате отправления: