Skip site navigation (1) Skip section navigation (2)

Re: Wrong FOR UPDATE lock type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <janwieck(at)Yahoo(dot)com>
Cc: "Mikheev, Vadim" <vmikheev(at)sectorbase(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Wrong FOR UPDATE lock type
Date: 2000-12-04 21:51:52
Message-ID: 7039.975966712@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jan Wieck <janwieck(at)Yahoo(dot)com> writes:
>     Tom,
>     IIRC  the  "Deadlock risk" debug message is from you. I think
>     it must get a little smarter. IMHO an application that want's
>     to  UPDATE  something  in  a  transaction but must SELECT the
>     row(s) first to do it's own calculation on them,  should  use
>     SELECT FOR UPDATE. Is that debug output really appropriate in
>     this case (it raises from  RowShareLock  to  RowExclusiveLock
>     because  of  the  UPDATE  of the previous FOR UPDATE selected
>     row)?

Well, there is a theoretical chance of deadlock --- not against other
transactions doing the same thing, since RowShareLock and
RowExclusiveLock don't conflict, but you could construct deadlock
scenarios involving other transactions that grab ShareLock or
ShareRowExclusiveLock.  So I don't think it's appropriate for the
"deadlock risk" check to ignore RowShareLock->RowExclusiveLock
upgrades.

But I'm not sure the check should be enabled in production releases
anyway.  I just put it in as a quick and dirty debug check.  Perhaps
it should be under an #ifdef that's not enabled by default.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Dan LykeDate: 2000-12-04 22:30:31
Subject: Re: Using Threads?
Previous:From: Alex PerelDate: 2000-12-04 21:49:27
Subject: INSERT INTO ... SELECT problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group