Re: recover corrupted pg_controldata from WAL - Mailing list pgsql-hackers

From yuanjia lee
Subject Re: recover corrupted pg_controldata from WAL
Date
Msg-id 20050722073910.56069.qmail@web34002.mail.mud.yahoo.com
Whole thread Raw
In response to Re: recover corrupted pg_controldata from WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@sss.pgh.pa.us> wrote:

> yuanjia lee <yuanjia_pg@yahoo.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 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Imprecision of DAYS_PER_MONTH
Next
From: Simon Riggs
Date:
Subject: Re: Writing Commit Status hint bits (was Re: Constant