Re: transaction error handling

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Kasia Tuszynska" <ktuszynska(at)esri(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: transaction error handling
Date: 2011-11-29 18:55:16
Message-ID: 4ED4D63402000025000435E8@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

Kasia Tuszynska <ktuszynska(at)esri(dot)com> wrote:

> Oracle:
> Begin transaction
> Insert - no error
> Implicit savepoint
> Insert - error raised
> Implicit rollback to the savepoint, no transaction loss, error
> raised on the insert statement that errored out.
> End transaction, implicit commit, with the single error free
> insert.
>
> Postgres:
> Begin transaction
> Insert - no error
> Insert - error raised
> Transaction loss = no implicit rollback to the single error free
> insert.
>
> Is this a correct interpretation of the Postgres transaction error
> handling?

Well, in psql you can set ON_ERROR_ROLLBACK so that each statement
will be automatically preceded by a SAVEPOINT which will be
automatically rolled back if the statement has an error. There are
various constructs for accomplishing this in supported PLs,
depending on the language.

I'm not aware of any "explicitly start a transaction but guess at
whether a commit is intended" feature in PostgreSQL. An explicit
transaction is committed if and when you say so.

-Kevin

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Kasia Tuszynska 2011-11-29 20:34:44 Re: transaction error handling
Previous Message Scott Marlowe 2011-11-29 18:36:20 Re: Deadlock on "select ... for update"?

Browse pgsql-bugs by date

  From Date Subject
Next Message Kasia Tuszynska 2011-11-29 20:34:44 Re: transaction error handling
Previous Message Rob Richardson 2011-11-29 18:34:49 Re: transaction error handling