Re: point in time recovery and moving datafiles online
От | Tatsuo Ishii |
---|---|
Тема | Re: point in time recovery and moving datafiles online |
Дата | |
Msg-id | 20020308104219G.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | 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
|
Список | 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 по дате отправления: