LOCK ROW SHARE MODE
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
"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