From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
Cc: | Andy Chambers <achambers(at)mcna(dot)net>, pgsql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Sequence moves forward when failover is triggerred |
Date: | 2012-07-12 00:42:51 |
Message-ID: | 4FFE1D8B.2020506@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 07/12/2012 04:17 AM, Steve Crawford wrote:
> The stickier issue is queuing. You have multiple users and need to
> ensure that you grab an unused check from the book but each concurrent
> user needs to get a different check. "Select from checkbook where not
> check_used order by check_no limit 1 for update" seems like a
> reasonable approach but if two users run it simultaneously the first
> user will get 1 check and succeed while the second user will attempt
> to lock same check record, block until the first user completes then
> recheck and find the selected record no longer
> meets the check_used criteria so the second user will see zero records
> returned.
In short-transaction systems where the blocking isn't an issue it's
often fine to just re-try when you don't get a result. Much simpler than
advisory locking tricks.
Using a SERIALIZABLE transaction should also work AFAIK, causing a
serialization failure and forcing the app to re-issue the transaction.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-07-12 01:07:37 | Re: PostgreSQL limitations question |
Previous Message | Craig Ringer | 2012-07-12 00:27:29 | Re: question about installation |