From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "[Jos_] Soares" <jose(at)sferacarta(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] DROP TABLE inside transaction block |
Date: | 1999-09-28 04:08:39 |
Message-ID: | 199909280408.AAA29897@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Any comment on this?
[Charset iso-8859-1 unsupported, filtering to ASCII...]
>
>
> Tom Lane ha scritto:
>
> > Pursuant to a phone conversation I had with Bruce, I added code this
> > morning to reject DROP TABLE or DROP INDEX inside a transaction block;
> > that is, you can't do BEGIN; DROP TABLE foo; END anymore. The reason
> > for rejecting this case is that we do the wrong thing if the transaction
> > is later aborted. Following BEGIN; DROP TABLE foo; ABORT, the system
> > tables will claim that foo is still valid (since the changes to them
> > were never committed) but we've already unlinked foo's physical file,
> > and we can't get it back. Solution: only allow DROP TABLE outside
> > BEGIN, so that the user can't try to change his mind later.
> >
> > However, on second thought I wonder if this cure is worse than the
> > disease. Will it be unreasonably hard to drop tables using client
> > interfaces that like to wrap everything in BEGIN/END? Plugging an
> > obscure hole might not be worth that.
> >
> > A possible compromise is not to error out, but just to issue a NOTICE
> > along the lines of "DROP TABLE is not undoable, so don't even think of
> > trying to abort now..."
> >
> > (Of course, what would be really nice is if it just worked, but I don't
> > see any way to make that happen without major changes. Simply
> > postponing the unlink to end of transaction isn't workable; consider
> > BEGIN; DROP TABLE foo; CREATE TABLE foo; ...)
> >
> > Any thoughts? Will there indeed be a problem with JDBC or ODBC if we
> > leave this error check in place?
> >
> > regards, tom lane
> >
> > ************
> >
> > ************
>
> Seems a good solution. I have an old note about this problem.
> What about to reject also the following commands inside transactions?
>
>
> * BUGS: There are some commands that doesn't work properly
> inside transactions. Users should NOT use the following
> statements inside transactions:
>
> - DROP TABLE -- in case of ROLLBACK only table structure
> will be recovered, data will be
> lost.
> - CREATE VIEWS -- the behavior of the backend is unpredictable.
> - ALTER TABLE -- the behavior of the backend is unpredictable.
> - CREATE DATABASE -- in case of ROLLBACK will be removed references
> from "pg_database" but directory
> $PGDATA/databasename will not be removed.
>
> Jos_
>
>
>
>
> ************
>
>
--
Bruce Momjian | http://www.op.net/~candle
maillist(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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-09-28 04:09:10 | Re: [HACKERS] DROP TABLE inside transaction block |
Previous Message | Bruce Momjian | 1999-09-28 04:08:12 | Re: [HACKERS] DROP TABLE inside transaction block |