Re: choosing the right locking mode

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

In response to

Responses

Browse pgsql-general by date

  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