From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LOCK ROW SHARE MODE |
Date: | 2001-10-24 04:34:17 |
Message-ID: | 16989.1003898057@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-10-24 04:53:14 | Re: [HACKERS] CREATE OR REPLACE VIEW/TRIGGER |
Previous Message | Christopher Kings-Lynne | 2001-10-24 02:56:12 | LOCK ROW SHARE MODE |