On 05/23/2010 08:19 PM, Tom Lane wrote:
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?=<gryzman@xxxxxxxxx> 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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
