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
