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
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 ? |
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, ...) |