| From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
|---|---|
| To: | "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Alvaro Herrera'" <alvherre(at)commandprompt(dot)com>, 'Cédric Villemain' <cedric(at)2ndquadrant(dot)com>, "'Pg Hackers'" <pgsql-hackers(at)postgresql(dot)org>, "'Robert Haas'" <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Allow WAL information to recover corrupted pg_controldata |
| Date: | 2012-06-21 03:24:45 |
| Message-ID: | 003001cd4f5d$6845cc50$38d164f0$@kapila@huawei.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> 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.
Yes, it can work the way you have explained or even by using Replication
solutions where
user can recreate the database from slave or other copy.
But the tool pg_resetxlog or similar tools are provided to handle situations
where user
has not taken care enough to be saved from corruption.
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2012-06-21 03:32:02 | Re: Allow WAL information to recover corrupted pg_controldata |
| Previous Message | Peter Geoghegan | 2012-06-21 02:17:14 | Re: sortsupport for text |