From: | "Mark Hollomon" <mhh(at)nortelnetworks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] DROP TABLE inside a transaction block |
Date: | 2000-03-08 13:05:20 |
Message-ID: | 38C65010.82B109FF@americasm01.nt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
>
> If we change the implementation so that the files are named after
> the (fixed, never-changed-after-creation) table OID, then RENAME
> TABLE is no problem: it affects *nothing* except the relname field
> of the table's pg_class row, and either that row update is committed
> or it ain't.
>
> But if the physical file names contain the logical table name, we
> have to be prepared to rename those files in sync with the transaction
> commit that makes the pg_class update valid. Quite aside from any
> implementation effort involved, the critical point is this: it is
> *not possible* to ensure that that collection of changes is atomic.
> At best, we can make the window for failure small.
>
How about using hard-links? The transaction that created the change
would see the new link along with the new tuple. other transactions
would see the old directory and the old tuple. rollback drops the new
tuple and the new directory entry. Commit does the obvious.
Does WinNT have something similar to a hard link?
--
Mark Hollomon
mhh(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Alan Dorman | 2000-03-08 14:04:27 | Re: [HACKERS] DROP TABLE inside a transaction block |
Previous Message | Hiroshi Inoue | 2000-03-08 10:12:43 | RE: [HACKERS] DROP TABLE inside a transaction block |