From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Leon <leon(at)udmnet(dot)ru>, Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] DROP TABLE inside transaction block |
Date: | 1999-09-07 01:44:19 |
Message-ID: | 37D46DF3.BBD5F1EB@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> There are a bunch of subtleties to be dealt with though. A couple of
> gotchas I can think of offhand: better flush dirty buffers for the
> target rel before doing the rename, else another backend might try to
> do it between DROP and COMMIT, and write to the wrong file name. The
BTW, I'm going to use relation oid as relation file name for WAL:
it would be bad to store relname in log records for each updated
tuple and it would be hard to scan pg_class to get relname from
reloid in recovery.
> renaming at abort time has to be done in the right order relative to
> dropping tables created during the xact, or else BEGIN; DROP TABLE foo;
> CREATE TABLE foo; ABORT won't work right. Currently, an attempt to
> lock a table always involves making a relcache entry first, and the
> relcache will try to open the underlying files as soon as you do that,
> so other backends trying to touch the dying table for the first time
> would get unexpected error messages. Probably a few other things.
>
> In short, a lot of work for a very marginal feature. How many other
> DBMSes permit DROP TABLE to be rolled back? How many users care?
Oracle auto-commits current in-progress transaction before
execution of any DDL statement and executes such statements in
separate transaction.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-09-07 02:53:29 | Re: [HACKERS] DROP TABLE inside transaction block |
Previous Message | Hiroshi Inoue | 1999-09-07 01:13:05 | RE: [HACKERS] DROP TABLE inside transaction block |