Re: transaction error handling

From: Kasia Tuszynska <ktuszynska(at)esri(dot)com>
To: Bèrto ëd Sèra <berto(dot)d(dot)sera(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: transaction error handling
Date: 2011-11-30 19:30:26
Message-ID: 232B5217AD58584C87019E8933556D11036BE6F613@redmx2.esri.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-bugs

Hi,
Oracle does not save the data, in mid transaction, in the sense of a commit.
It keeps the association of the memory address related to the error free changes to the transaction and allows you – the developer to capture the error on that single incorrect change, and then continue with the subsequent sql statements that are part of that long transaction.
While in that state, the changes pertaining to that transaction are not written to any logs and are not written to file, you can still roll back the entire transaction.
Only when a commit occurs, does the transaction get written to SGA, archiving, file etc…

With Postgres that is not the case, if the 50th sql statement in a long transaction incurs an error, the whole transaction is rolled back for you automatically, you the developer have no say in that unless you bracket each statement with a savepoint creation and destruction, just to be able to capture the potential error that may arise on that 50th sql statement.

Sincerely,
Kasia
From: pgsql-admin-owner(at)postgresql(dot)org [mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Bèrto ëd Sèra
Sent: Wednesday, November 30, 2011 12:49 AM
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: [ADMIN] transaction error handling

On 29 November 2011 21:34, Rob Richardson <RDRichardson(at)rad-con(dot)com<mailto:RDRichardson(at)rad-con(dot)com>> wrote:
If Oracle saves half of the data between the beginning and ending of the transaction, doesn't that defeat the purpose of the transaction?

It sure enough kills Atomicity. I can see a use for this on importing data from external sources that may violate existing unique keys, so illegal inserts are ignored, but you still are left without any knowledge of what rows where silently dropped. Since when is Oracle doing this, FMI? (It's been a long while since I used it for anything serious)

Bèrto

--
==============================
If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Craig Ringer 2011-11-30 23:36:54 Re: transaction error handling
Previous Message Craig James 2011-11-30 18:08:42 Re: Deadlock on "select ... for update"?

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2011-11-30 20:36:11 Re: BUG #6067: In PL/pgsql, EXISTS(SELECT ... INTO...) fails
Previous Message Nicholson, Brad (Toronto, ON, CA) 2011-11-30 13:19:40 Re: transaction error handling