Re: transaction error handling - Mailing list pgsql-admin

From Nicholson, Brad (Toronto, ON, CA)
Subject Re: transaction error handling
Date
Msg-id EC55DC235432104F8255702A8D7344D9256FF62B@G9W0741.americas.hpqcorp.net
Whole thread Raw
In response to Re: transaction error handling  (Kasia Tuszynska <ktuszynska@esri.com>)
List pgsql-admin
> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-
> owner@postgresql.org] On Behalf Of Kasia Tuszynska
> Sent: Tuesday, November 29, 2011 3:35 PM
> To: Kevin Grittner; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] transaction error handling
>
> Hi Kevin,
> Thank you, that is very helpful.
> I am not worried about the implicit commits. The "no implicit
> savepoint" was more of an issue, since it created a necessity to create
> and destroy savepoints per each sql statement to capture any statement
> level error without losing a transaction, that approach has prohibitive
> performance repercussions.
> I will check out the ON_ERROR_ROLLBACK feature.
> Thank you,
> Sincerely,
> Kasia


Be aware that this option is a psql option and not one in the database itself, which means unless you are executing
yourSQL via psql it will not be of help to you. 

Also the implementation of this is that psql issues implicit savepoints for you before each command in a transaction
andhandles the rollback for you if needed (which sounds an awful lot like the performance concern you have). 

This is a major pain for porting Oracle based applications over for those that rely on this functionality.

Brad.


pgsql-admin by date:

Previous
From: Kasia Tuszynska
Date:
Subject: Re: transaction error handling
Next
From: Lukasz Brodziak
Date:
Subject: Re: Database is in recovery mode.