Re: Point in time recovery: recreating relation files
От | Marc Munro |
---|---|
Тема | Re: Point in time recovery: recreating relation files |
Дата | |
Msg-id | 1015516985.29579.0.camel@bloodnok.com обсуждение исходный текст |
Ответ на | Re: Point in time recovery: recreating relation files (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Point in time recovery: recreating relation files
|
Список | 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 по дате отправления: