Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id D8BF1476BA8 for ; Fri, 18 Oct 2002 14:03:13 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 4D7B1476B92 for ; Fri, 18 Oct 2002 14:03:13 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9II3ChR019056; Fri, 18 Oct 2002 14:03:13 -0400 (EDT) To: Ludwig Lim Cc: PostgreSQL Mailing List Subject: Re: Locking that will delayed a SELECT In-reply-to: <20021018150234.23205.qmail@web80305.mail.yahoo.com> References: <20021018150234.23205.qmail@web80305.mail.yahoo.com> Comments: In-reply-to Ludwig Lim message dated "Fri, 18 Oct 2002 08:02:34 -0700" Date: Fri, 18 Oct 2002 14:03:12 -0400 Message-ID: <19055.1034964192@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/239 X-Sequence-Number: 9956 Ludwig Lim writes: > *** For clarification *** > In the SQL command reference of PostgreSQL: > in SELECT statement section : > "The FOR UPDATE clause allows the SELECT > statement to perform exclusive locking of selected > rows" Hmm. That is a misstatement: FOR UPDATE only locks the selected row(s) against other updates (ie UPDATE, DELETE, SELECT FOR UPDATE), so it's not "exclusive" in the usual sense of the word: readers can still see the row. I'll fix that for 7.3, but meanwhile you might care to read the 7.3 development docs' discussion of concurrency, which is (IMHO anyway) more accurate than what was there before: http://developer.postgresql.org/docs/postgres/mvcc.html Note in particular that table-level locks and row-level locks are two independent features. Updates acquire an appropriate table-level lock and then acquire row locks on the rows they are updating. regards, tom lane