Re: [HACKERS] DROP TABLE inside a transaction block

> 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.
>
> Bruce seems to be willing to accept a window of failure for RENAME
> TABLE in order to make database admin easier. That is very possibly
> the right tradeoff --- but it is *not* an open-and-shut decision.
> We need to talk about it.

How about creating a hard link during RENAME, and you can just remove
the old link on commit or remove the new link on transaction rollback?

We can register this in the at_exit processing too if you think it is
necessary to clean it up on a backend crash that never gets to an abort,
though I think abort is always called.

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026