On 05/23/2010 08:19 PM, Tom Lane wrote:
> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?=<gryzman@gmail.com> writes:
>> find in docs part that talks about transaction isolation levels, and
>> translate it to your problem.
>
> Yes, please read the fine manual:
> http://www.postgresql.org/docs/8.4/static/mvcc.html
>
> What I think will happen in your example is that all concurrent
> executions will locate the same row-to-be-updated. The first one to get
> to the row "wins" and updates the row. All the rest will fail, either
> updating no rows (if not serializable) or throwing an error (if
> serializable).
>
OK, thank you both, I had hoped that UPDATE would take a table level
lock before running the inner select. But then I read that the type of
locking done by UPDATE never conflicts with other such locks, so the
queries would still run concurrently. We're running the default Read
Commited mode. It's no problem for me to rewrite the Perl DBI query to
check the return value and loop until it does get something. Which would
have better performance: that, or an explicit LOCK on the table before
the UPDATE ... SELECT? The transaction is committed shortly after, with
no other queries in between.
Thank you.