"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
