Skip site navigation (1) Skip section navigation (2)

Re: transaction error handling

From: Kasia Tuszynska <ktuszynska(at)esri(dot)com>
To: Walter Hurry <walterhurry(at)lavabit(dot)com>, "pgsql-admin(at)postgresql(dot)org"<pgsql-admin(at)postgresql(dot)org>
Subject: Re: transaction error handling
Date: 2011-11-29 22:08:11
Message-ID: 232B5217AD58584C87019E8933556D11036BE6ED93@redmx2.esri.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-bugs
Hi,
Yes, I believe that you are right.

As far as I can gather, the postgres transaction error handling is like oracle stored procedures. If you do not catch the error the whole transaction is rolled back. I am curious why Postgres has gone with a model that does not allow the user a choice to deal with the statement level errors that may arise in a long transaction. 

That either calls for very short transactions or an introduction of explicit savepoint creation and explicit savepoint destruction for every statement, if you - the user, want the ability to deal with statement errors that may arise. 

I realize that it is almost impossible to change that architecture now, since it would be such a low level change, but I am surprised that it is not a common complaint from the user community, since bulk ddl loads would truly suffer. 

I do not wish to compare Postgres to Oracle per se, I used oracle because I am more familiar with it than the Sql Server transaction model, they did a rewrite on transaction handling for SS 2005 and I never fully got into it. 

Sincerely,
Kasia 

-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org [mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Walter Hurry
Sent: Tuesday, November 29, 2011 12:50 PM
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] transaction error handling

On Tue, 29 Nov 2011 09:57:24 -0800, Kasia Tuszynska wrote:

> Hi Everybody,
> 
> This is an architectural question.
> I am testing on Postgres 9.0.2 on windows and linux(suse, rhel, ubuntu)
> 
> I want to make sure that I have the correct understanding of the
> Postgres architecture and would like to enquire if there are any plans
> to change it.
> 
> Comparing Oracle and Postgres from the perspective of error handling on
> the transaction level I observed the following:
> 
> 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?
> If so, are there any changes being considered, or perhaps already
> implemented?

I suspect you may be barking up the wrong tree. Comparing default 
behaviour of PSQL to SQL*Plus is not the same thing as comparing 
PostgreSQL to Oracle.



-- 
Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

In response to

pgsql-admin by date

Next:From: senthilnathanDate: 2011-11-30 05:52:14
Subject: Read Only Role
Previous:From: Nicholson, Brad (Toronto, ON, CA)Date: 2011-11-29 22:06:48
Subject: Re: transaction error handling

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2011-11-30 02:32:42
Subject: Re: BUG #6067: In PL/pgsql, EXISTS(SELECT ... INTO...) fails
Previous:From: Nicholson, Brad (Toronto, ON, CA)Date: 2011-11-29 22:06:48
Subject: Re: transaction error handling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group