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 20020308104219G.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>)
List pgsql-hackers
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > What would happen if a table is dropped or truncated while doing tar
> > on it?
> 
> Nothing bad, unless tar itself got confused.  (Which could perhaps
> happen in the TRUNCATE case; I dunno if tar is happy when it can't read
> as much from the file as it originally expected.)  As far as DROP goes,
> any standard Unix system will postpone the physical file delete until
> the last open file descriptor closes.

My concern is after DROP TABLE is committed. In my understanding when
the backup process starts,it records a LSN somewhere (maybe
pg_control?) to remember the place where the archive log recovery
could start later.

Consider a scenario:

(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?
--
Tatsuo Ishii


pgsql-hackers by date:

Previous
From: Fernando Nasser
Date:
Subject: Re: Libpq support for precision and scale
Next
From: Bruce Momjian
Date:
Subject: Re: Libpq support for precision and scale