Re: [HACKERS] DROP TABLE inside transaction block
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] DROP TABLE inside transaction block |
Дата | |
Msg-id | 199909281526.LAA19666@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] DROP TABLE inside transaction block (José Soares <jose@sferacarta.com>) |
Список | pgsql-hackers |
Tom Lane is working on this, and it should be improved for 6.6. [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@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
В списке pgsql-hackers по дате отправления: