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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026