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.