Re: recover corrupted pg_controldata from WAL

From: yuanjia lee <yuanjia_pg(at)yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: recover corrupted pg_controldata from WAL
Date: 2005-07-22 07:39:10
Message-ID: 20050722073910.56069.qmail@web34002.mail.mud.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom

I agree that it is wrong to use the information from
the file name itself. I will try to read the
xlp_pageaddr out from the segment header to figure out
which one is the lastest one.

In the mutilple time lines scenario, if the pg_control
file crashed, and the current time line information
will be lost. Altough we can let the user the select
the possible time line, but the implementation until
now is using the highest time line number.

--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> yuanjia lee <yuanjia_pg(at)yahoo(dot)com> writes:
> > The algorithm of searching the WAL is like this:
>
> > 1. Read name of the segment files from xlog
> directory, and put all of their name into an one way
> list, the list is descending according to the time
> line, xlog id, segement id. (Athough I use only the
> lastest file in the implementation, but the list can
> be used for the feature like dump log in future.)
>
> You do realize that in most situations, the segment
> files with the
> newest-looking names have not been used yet, and
> contain older rather
> than newer data?
>
> When multiple timelines are present, I'm not sure I
> care for the
> heuristic "use the highest timeline number", either.
>
> regards, tom lane
>


____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2005-07-22 07:51:26 Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant
Previous Message Bruce Momjian 2005-07-22 05:06:38 Re: Imprecision of DAYS_PER_MONTH