From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | Emi Lu <emilu(at)cs(dot)concordia(dot)ca>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Questions about Rollback - after insert, update, delete ... operations? |
Date: | 2005-09-23 13:53:07 |
Message-ID: | 3300.1127483587@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
>> I wasn't able to find where this is spelled out in the documentation,
>> but I believe all DDL commands except DROP DATABASE can be rolled back now.
> I don't think there's any all-in-one-place statement about it, but
> anything that doesn't explicitly object to being put inside a
> transaction block can be rolled back. Grepping for
> PreventTransactionChain, I see that the current suspects are
> CLUSTER (only the multi-table variants)
> CREATE DATABASE
> DROP DATABASE
> REINDEX DATABASE
> CREATE TABLESPACE
> DROP TABLESPACE
> VACUUM
As of 8.1, REINDEX SYSTEM needs to be listed as well.
In this context, it may be worth pointing out that CLUSTER, VACUUM, and
REINDEX are all *internally* roll-back-able, as is essential for crash
safety. The reason they object to being inside a transaction block is
that they want to start and end their own transactions internally so
that they can process each table in a separate transaction.
So, CREATE/DROP DATABASE and CREATE/DROP TABLESPACE really are the only
operations Postgres cannot roll back.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Seberg | 2005-09-23 14:03:44 | COPY - permission denied |
Previous Message | Michael Fuhr | 2005-09-23 13:40:21 | Re: SQL command to dump the contents of table failed: PQendcopy() failed. Error message from server: socket not open |