Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 3DEBA47601E for ; Thu, 24 Oct 2002 09:42:44 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 92DF5475FB5 for ; Thu, 24 Oct 2002 09:42:43 -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 g9ODglhR011293; Thu, 24 Oct 2002 09:42:47 -0400 (EDT) To: Ludwig Lim Cc: PostgreSQL Mailing List Subject: Re: Simulating a SELECT..FOR UPDATE to LOCK and SELECT statement In-reply-to: <20021024041032.93394.qmail@web80313.mail.yahoo.com> References: <20021024041032.93394.qmail@web80313.mail.yahoo.com> Comments: In-reply-to Ludwig Lim message dated "Wed, 23 Oct 2002 21:10:32 -0700" Date: Thu, 24 Oct 2002 09:42:46 -0400 Message-ID: <11292.1035466966@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/335 X-Sequence-Number: 10052 Ludwig Lim writes: > Is there a way to emulate a SELECT..FOR UPDATE to > series of LOCK/SELECT statement. No. LOCK can only acquire table-level locks; the point of SELECT FOR UPDATE is to acquire row-level locks. > I am surprised because according to the docs > (version 7.2), it says: > ROW SHARE MODE > Note: Automatically acquired by SELECT ... FOR > UPDATE. SELECT FOR UPDATE gets a table-level lock just to ensure that the table doesn't disappear from under it while it's doing its scan. The ROW SHARE lock is pretty weak though, and doesn't block anything less drastic than DROP/ALTER TABLE or VACUUM FULL. The 7.3 development docs are perhaps clearer about this; try http://developer.postgresql.org/docs/postgres/explicit-locking.html regards, tom lane