Hi All,

In the LOCK TABLE docs it documents the SELECT...FOR UPDATE as follows:


----
ROW SHARE MODE
Note: Automatically acquired by SELECT...FOR UPDATE. While it is a shared
lock, may be upgraded later to a ROW EXCLUSIVE lock.

Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
----

However, if I begin a transaction in one window and SELECT...FOR UPDATE a
row, then begin a transaction in another window and SELECT ... FOR UPDATE
the same row, the second SELECT..FOR UPDATE blocks until the first
transactions is committed or rolled back.

So, shouldn't this mean that the ROW SHARE mode should in fact be documented
to conflict with itself???  And with this behaviour is it really a shared
lock?  I don't get it!

Chris



Wed, 24 Oct 2001 10:56:12 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
LOCK ROW SHARE MODE
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> In the LOCK TABLE docs it documents the SELECT...FOR UPDATE as follows:

> ROW SHARE MODE
> Note: Automatically acquired by SELECT...FOR UPDATE. While it is a shared
> lock, may be upgraded later to a ROW EXCLUSIVE lock.
> Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.

> However, if I begin a transaction in one window and SELECT...FOR UPDATE a
> row, then begin a transaction in another window and SELECT ... FOR UPDATE
> the same row, the second SELECT..FOR UPDATE blocks until the first
> transactions is committed or rolled back.

> So, shouldn't this mean that the ROW SHARE mode should in fact be documented
> to conflict with itself???  And with this behaviour is it really a shared
> lock?  I don't get it!

ROW SHARE is a table-level lock mode.  SELECT FOR UPDATE grabs ROW SHARE
lock on the table, *plus* an exclusive-write lock on the selected row(s).
The latter is what's conflicting for you.

I think the code is okay, but the documentation could use some work...

			regards, tom lane

Wed, 24 Oct 2001 00:34:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: LOCK ROW SHARE MODE 