Re: Allow WAL information to recover corrupted pg_controldata
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Amit Kapila <amit.kapila@huawei.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@commandprompt.com>, Cédric Villemain <cedric@2ndquadrant.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-06-20T16:07:49Z
Lists: 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