Re: point in time recovery and moving datafiles online - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: point in time recovery and moving datafiles online
Date
Msg-id 20020308110033H.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: point in time recovery and moving datafiles online  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: point in time recovery and moving datafiles online  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: point in time recovery and moving datafiles online  (Marc Munro <marc@bloodnok.com>)
List pgsql-hackers
> > (1) backup process starts (and records LSN)
> > (2) DROP TABLE t1 starts
> > (3) DROP TABLE t1 commits
> > (4) backup process ends
> 
> > I think the database status should be able to go back to (1) using
> > the archive log recovery. No?
> 
> No.  It is not reasonable to expect the backup to allow you to recreate
> any state occurring before the *end* of the backup process.  After the
> backup is complete, you can use the backup and the WAL to duplicate the
> state of any later instant.

I see your point. But is it reasonable? We cannot know when the backup
process completes beforehand and that makes the archive log recovery
less usefull in my opinion.

I guess Oracle and other commercial DBMSs declare the start of backup
process explicitly and that would be the point where the archive log
recovery could go back. I'm interested in how Oracle accomplishes this
(I know DROP TABLE is not rollbackable in Orale).
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Libpq support for precision and scale
Next
From: Tom Lane
Date:
Subject: Re: TODO question