Re: point in time recovery and moving datafiles online

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
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 01:03:07
Message-ID: 25131.1015549387@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2002-03-08 01:12:28 Re: pl/pgsql Composite Parameter Question
Previous Message Justin Clift 2002-03-08 01:01:49 PostgreSQL for PS/2 ?

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-03-08 01:03:52 Re: TODO question
Previous Message Bruce Momjian 2002-03-08 01:01:44 Re: patch: INSERT INTO t VALUES (a, b, ..., DEFAULT, ...)