From: | Evan Simpson <evan(at)4-am(dot)com> |
---|---|
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-06 17:10:15 |
Message-ID: | 37D3F577.30EB4884@4-am.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here's some comments from a naive viewpoint (moving from InterBase to
PostgreSQL):
Tom Lane wrote:
> So someone could probably cobble together a real solution consisting of
> locking the table and renaming the files to unique temp names at DROP
> time, then either completing the drop and unlinking the files at commit
> time, or re-renaming them at abort.
Why should all of this renaming stuff be necessary? I would expect all
entities CREATEd in a transaction to live entirely in cache (or a temp file),
and all DROPped entities to remain where they are until COMMIT time, at which
point DROPs should unlink and then CREATEs should create. Is this too hard?
> 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?
Sybase documentation explicitly allows most forms of CREATE and DROP in
transactions. InterBase (which uses a versioning system much like
PostgreSQL) definitely handles CREATE/DROP in transactions correctly, but you
can't access a newly created table until after COMMIT.
What happens, in the current system if you want to make metadata changes in a
transaction and you make a typo that requires ABORTing the changes? If you
have to make all metadata changes outside of transactions, you lose safety at
the most fragile and critical level.
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 1999-09-06 17:21:02 | Troubles from using pg_dumpall with dbname |
Previous Message | Leon | 1999-09-06 16:02:07 | Re: [HACKERS] DROP TABLE inside transaction block |