On Tue, 2006-03-28 at 14:56 +0200, David Welton wrote: > There are two processes, A, and B. > > A is a daemon process that performs a select, and then slowly iterates > over the results, performing updates along the way. > > It is possible that interactive process B comes along, and wants to > change the data that A is working with. B should not 1) hang or 2) > fail (it's interactive, and in this case the user is always right). > It's not optimal, but it would be ok if A failed - indeed, it would be > better than if it kept working with the (now incorrect) data that it > pulled from the select prior to the user's intervention. A should use serializable transaction, so it will fail whenever it sees a row updated by B. That way A will fail as you request. Try breaking down the A query with LIMIT/OFFSET so that it never holds locks for long. That way B will not wait for long, if at all, and will not fail. Best Regards, Simon Riggs
