Re: Questions about Rollback - after insert, update, delete ... operations?

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

In response to

Browse pgsql-general by date

  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