From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | rihad <rihad(at)mail(dot)ru> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: choosing the right locking mode |
Date: | 2008-04-03 17:45:59 |
Message-ID: | 47F517D7.80709@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
rihad wrote:
> Given this type query:
>
> UPDATE bw_pool
> SET user_id=?
> WHERE bw_id=
> (SELECT MIN(bw_id) FROM bw_pool WHERE user_id IS NULL)
> RETURNING bw_id
Can you use a SERIALIZABLE transaction and avoid the explicit lock?
If I'm not mistaken, using the SERIALIZABLE isolation level should
ensure that the following cannot occur:
UPDATE begins
UPDATE begins
Subquery finds free row id 1
Subquery finds free row id 1
Update completes
Update completes, overwriting
changes from the other update.
You'd have to be prepared to retry failed updates, but I doubt that's a
big deal in this situation.
See:
http://www.postgresql.org/docs/8.2/interactive/transaction-iso.html
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2008-04-03 17:54:45 | Re: choosing the right locking mode |
Previous Message | Aidan Van Dyk | 2008-04-03 17:44:34 | Re: modules |