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

Re: [HACKERS] Errors inside transactions

From: Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at>
To: "pgsql-hackers(at)postgreSQL(dot)org" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Errors inside transactions
Date: 1998-09-22 06:46:34
Message-ID: 01BDE605.96A14BE0@zeugswettera.user.lan.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> Or do you really want to commit the previous statements in the
> transaction rather than throw them away? If so, you didn't really need
> the transaction block there anyway, since you are willing to accept a
> partial result.

Actually the postgresql behavior on error has been nagging on me also (OK, only a little bit). 
Yes, the usual behavior is for the application to decide if it wants to roll back 
all other work on error or go on and correct the error and then commit all work 
even if one part did not succeed.

This is what is usually done, and actually helps performance since it saves one select:


begin work;
	do arbitrary work
	insert   /* violates primary key constraint --> ERROR  */ 
	on error do instead update the offending row
	do other work
commit work;

The decision on whether to do the update or the insert first is based on frequency of 
successful events for the first statement. 
(more inserts --> insert first, more updates --> update first)
All commercial DBMS's handle it this way, it is probably even in ANSI.

Andreas
	


pgsql-hackers by date

Next:From: Jose' SoaresDate: 1998-09-22 09:12:17
Subject: Re: [HACKERS] current- crash
Previous:From: Bruce MomjianDate: 1998-09-22 04:47:21
Subject: Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]

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