Re: [HACKERS] DROP TABLE inside transaction block

Поиск
Список
Период
Сортировка
От José Soares
Тема Re: [HACKERS] DROP TABLE inside transaction block
Дата
Msg-id 37D50B5C.636B68C2@sferacarta.com
обсуждение исходный текст
Ответ на DROP TABLE inside transaction block  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] DROP TABLE inside transaction block  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] DROP TABLE inside transaction block  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] DROP TABLE inside transaction block  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers

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
backendis unpredictable.    - CREATE DATABASE -- in case of ROLLBACK will be removed references
from"pg_database" but directory
 
$PGDATA/databasename will not be removed.

José





В списке pgsql-hackers по дате отправления:

Предыдущее
От: José Soares
Дата:
Сообщение: Re: [HACKERS] SELECT BUG
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] PostgreSQL 6.5.1: libpq++ libraries on IRIX 6.5