From: | "John D(dot) Burger" <john(at)mitre(dot)org> |
---|---|
To: | General PostgreSQL List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Need LIMIT and ORDER BY for UPDATE |
Date: | 2007-12-13 13:44:51 |
Message-ID: | D2D51CCC-A554-41DF-BF76-FD3F7DB2AFD0@mitre.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
D. Dante Lorenso wrote:
> Doesn't this create race condition in the query where multiple
> processes might find the same invoice_id while executing the inner
> select. The update would then update the same record more than
> once during the update step and 2 processes might get the same
> invoice_id returned. In otherwords, moving the select criteria
> into a sub-query breaks the atomic nature of the update. Right?
Hmm, dunno. Sorry, my grasp of concurrency issues is still infantile.
> I have been trying to doing something like this, though:
...
> By checking the reserve_ts inside the SELECT and again inside the
> UPDATE this should catch the race condition and only allow one
> process to perform the update on a given match. If the other
> process has updated the reserve_ts already, the reserve_ts would
> not pass the second check. However, the new side-effect is that
> one process would receive a NULL return result when the race
> condition occurs rather than just picking up the next queue
> invoice_id.
But this could happen in any event, if there are no more invoices to
process, yes? I'm picturing a set of queue consumers, each of which
is already looping around such issues, anyway.
- John D. Burger
MITRE
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2007-12-13 13:57:51 | Re: slony question |
Previous Message | Bill Moran | 2007-12-13 13:37:39 | Re: Need LIMIT and ORDER BY for UPDATE |