From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | marc(at)bloodnok(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: point in time recovery and moving datafiles online |
Date: | 2002-03-08 02:00:33 |
Message-ID: | 20020308110033H.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-08 02:03:54 | Re: PostgreSQL for PS/2 ? |
Previous Message | Bruce Momjian | 2002-03-08 01:50:57 | Re: PostgreSQL for PS/2 ? |
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Nasser | 2002-03-08 02:02:25 | Re: Libpq support for precision and scale |
Previous Message | Bruce Momjian | 2002-03-08 01:57:24 | Re: Libpq support for precision and scale |