Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 503BE9F9392 for ; Fri, 1 Dec 2006 13:41:03 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 21746-08 for ; Fri, 1 Dec 2006 13:40:50 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id AB05B9FA26D for ; Fri, 1 Dec 2006 13:40:50 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kB1HekOc000535; Fri, 1 Dec 2006 12:40:46 -0500 (EST) To: "Heikki Linnakangas" cc: "Alvaro Herrera" , "Simon Riggs" , pgsql-hackers@postgreSQL.org Subject: Re: FOR SHARE vs FOR UPDATE locks In-reply-to: <45705E9C.2060003@enterprisedb.com> References: <1144.1164924373@sss.pgh.pa.us> <1164962544.3778.847.camel@silverbirch.site> <20061201113711.GC30441@alvh.no-ip.org> <15834.1164985926@sss.pgh.pa.us> <45705E9C.2060003@enterprisedb.com> Comments: In-reply-to "Heikki Linnakangas" message dated "Fri, 01 Dec 2006 16:55:56 +0000" Date: Fri, 01 Dec 2006 12:40:46 -0500 Message-ID: <534.1164994846@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/26 X-Sequence-Number: 94507 Actually ... wait a minute. The proposed hack covers the case of SELECT FOR SHARE followed by SELECT FOR UPDATE within a subtransaction. But what about SELECT FOR SHARE followed by an actual UPDATE (or DELETE)? We certainly don't want to mark the UPDATE/DELETE as having been carried out by the upper transaction, but there's no way we can record the UPDATE while still remembering the previous share-lock. So I think I'm back to the position that we should throw an error here. regards, tom lane