Re: Allow WAL information to recover corrupted pg_controldata

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Amit kapila <amit(dot)kapila(at)huawei(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-18 16:43:29
Message-ID: 12582.1340037809@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of sb jun 16 02:41:00 -0400 2012:
>> Well, we invented pg_resetxlog with the thought that it might be useful
>> for such situations, but I'm not sure offhand that we've ever seen a
>> field report of corrupted pg_control files.

> Hm, what about the situation where pg_control is lost completely to a
> filesystem failure? I remember doing disaster recovery on this problem
> once ... As far as I recall the pg_xlog files were in a separate
> partition so they weren't lost. Some other files in the main data
> partition were lost as well.

Hm ... well, as long as we have a clear idea of a use-case, I'm not
opposed in principle to working on this area.

> (I don't remember what is it that we had
> to do to create a fake pg_control).

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2012-06-18 17:09:06 Re: temporal support patch
Previous Message Alvaro Herrera 2012-06-18 16:34:47 Re: Allow WAL information to recover corrupted pg_controldata