Re: choosing the right locking mode - Mailing list pgsql-general

From Craig Ringer
Subject Re: choosing the right locking mode
Date
Msg-id 47F517D7.80709@postnewspapers.com.au
Whole thread Raw
In response to choosing the right locking mode  (rihad <rihad@mail.ru>)
Responses Re: choosing the right locking mode  ("Scott Marlowe" <scott.marlowe@gmail.com>)
List 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

pgsql-general by date:

Previous
From: brian
Date:
Subject: Re: Secure "where in(a,b,c)" clause.
Next
From: Sam Mason
Date:
Subject: Re: choosing the right locking mode