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

From Tom Lane
Subject Re: point in time recovery and moving datafiles online
Date
Msg-id 25131.1015549387@sss.pgh.pa.us
Whole thread Raw
In response to Re: point in time recovery and moving datafiles online  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: point in time recovery and moving datafiles online  (Tatsuo Ishii <t-ishii@sra.co.jp>)
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.

> I think we do not perform any logging while doing DROP TABLE or
> TRUCATE TABLE.

TRUNCATE isn't considered rollback-able anyway (indeed that's its whole
point) so I'm not too excited about whether or not it plays by the WAL
rules.  CREATE/DROP DATABASE the same.

As for DROP TABLE, what should happen is that at commit time we log the
IDs of the tables being deleted in WAL; then on replay we can re-delete
them as needed.  If you look in xact.c you will see comments where this
is supposed to happen --- but evidently Vadim never did get around to
that.  Other file creation and deletion actions need to be logged in WAL
as well.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] system catalog relation of a table and a serial
Next
From: Bruce Momjian
Date:
Subject: Re: TODO question