Re: Allow WAL information to recover corrupted pg_controldata
От | Tom Lane |
---|---|
Тема | Re: Allow WAL information to recover corrupted pg_controldata |
Дата | |
Msg-id | 4274.1340084598@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allow WAL information to recover corrupted pg_controldata (Amit Kapila <amit.kapila@huawei.com>) |
Ответы |
Re: Allow WAL information to recover corrupted pg_controldata
Re: Allow WAL information to recover corrupted pg_controldata Re: Allow WAL information to recover corrupted pg_controldata |
Список | pgsql-hackers |
Amit Kapila <amit.kapila@huawei.com> writes: >> AFAIR you can create pg_control from scratch already with pg_resetxlog. >> The hard part is coming up with values for the counters, such as the >> next WAL location. Some of them such as next OID are pretty harmless >> if you don't guess right, but I'm worried that wrong next WAL could >> make things worse not better. > I believe if WAL files are proper as mentioned in Alvaro's mail, the > purposed logic should generate correct values. I've got a problem with the assumption that, when pg_control is trash, megabytes or gigabytes of WAL can still be relied on completely. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: