Re: Transaction Exception Question

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Jon Swinth <jswinth(at)atomicpc(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Transaction Exception Question
Date: 2002-08-13 16:40:55
Message-ID: Pine.LNX.4.33.0208131036280.17162-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 13 Aug 2002, Jon Swinth wrote:

> A while back, I ran into a problem that turned out to be in Postgre on
> purpose. In a long running transaction (or any transaction for that matter)
> if an exception is thrown then you have no choice but to rollback that
> transaction. Is there someone that can point me in the right direction in
> finding out why this would be? It has bitten me a few times and will limit
> Postgre's ability to work in a high volume operation.

Seeing as how the purpose of a transaction is to ensure that either all
the changes to the database are made or none are made, I'm not sure what
should change about this behaviour.

Or were you looking for things like commit / rollback segments? In
general, instead of using commit / rollback segments I just do a begin /
end pair around each set of data that I would have used a commit /
rollback segment.

Sometimes I think postgresql's tendency to get pedantic about which errors
cause an auto abort is a little bothersome (i.e. an error thrown by a
select or set statement will abort the current transaction) but for
update/delete/insert commands, and single error SHOULD cause the whole
transaction to abort, thus ensuring transactional integrity.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jon Swinth 2002-08-13 16:42:52 Transaction Exception Question
Previous Message Andrew Sullivan 2002-08-13 16:40:46 Re: [HACKERS] Linux Largefile Support In Postgresql RPMS