| From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "'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-19 08:46:46 |
| Message-ID: | 002b01cd4df8$0fd6dca0$2f8495e0$@kapila@huawei.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I'm almost inclined to suggest that we not get next-LSN from WAL, but
> by scanning all the pages in the main data store and computing the max
> observed LSN. This is clearly not very attractive from a performance
> standpoint, but it would avoid the obvious failure mode where you lost
> some recent WAL segments along with pg_control.
If we follow this approach, what should be handling in case next-LSN is greater than
last checkpoint record location read from WAL files. Currently I can see StratUpXLOG throws
PANIC error in such situation.
I think this can happen in case of missing some recent WAL segments.
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2012-06-19 09:41:49 | Re: [PATCH] Lazy hashaggregate when no aggregation is needed |
| Previous Message | Boszormenyi Zoltan | 2012-06-19 08:44:35 | Re: [PATCH] lock_timeout and common SIGALRM framework |