Re: Point in time recovery: recreating relation files - Mailing list pgsql-hackers

From Marc Munro
Subject Re: Point in time recovery: recreating relation files
Date
Msg-id 1015516985.29579.0.camel@bloodnok.com
Whole thread Raw
In response to Re: Point in time recovery: recreating relation files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Point in time recovery: recreating relation files
List pgsql-hackers
Could someone explain to this poor newbie (who is hoping to implement
this) exactly what the issue is here?  Like Tom, I could originally see
no reason to worry about the LSN for file creation but I am very
concerned that I have failed to grasp Tatsuo's concerns.

Is there some reason why the relfilenode might change either during or
as a result of recovery?  Unless I have missed the point again, during
recovery we must recreate files with exactly the same path, name and
relfilenode as they would have originally been created, and in the same
order relative to the creation of the relation.  I see no scope for
anything to be different.


On Wed, 2002-03-06 at 21:29, Tom Lane wrote:
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> >> But undo/redo checking on file creation or deletion is trivial: either
> >> the kernel has the file or it doesn't.  We do not need any other check
> >> AFAICS.
> 
> > Are you saying that the table creation log record would contain a
> > relfilenode?
> 
> Sure.  What else would it contain?
> 
> > I'm not sure the relfilenode is same before and after the
> > recovery if we consider the point time recovery.
> 
> Considering that all the WAL entries concerning updates to the table
> will name it by relfilenode, we'd better be prepared to ensure that
> the relfilenode doesn't change over recovery.
> 
>             regards, tom lane
-- 
Marc        marc@bloodnok.com


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: Bad Build
Next
From: "Rod Taylor"
Date:
Subject: Re: Current cvs source regression: create_function_1.out