| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | David Welton <davidnwelton(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Concurrency question |
| Date: | 2006-03-28 13:45:46 |
| Message-ID: | 1143553546.3839.355.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Csaba Nagy | 2006-03-28 13:56:17 | Re: Concurrency question |
| Previous Message | Martijn van Oosterhout | 2006-03-28 13:28:58 | Re: deleting function from pg_catalog.pg_proc |