Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id D90099F9F0E; Fri, 1 Dec 2006 16:47:33 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 13731-07; Fri, 1 Dec 2006 16:47:19 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id C03139FA12B; Fri, 1 Dec 2006 16:47:21 -0400 (AST) thread-index: AccVieeWRpoYhtk8StuNdGtjTTP7hg== Received: from [192.168.0.20] ([84.12.196.220]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 15:47:23 -0500 Subject: Re: FOR SHARE vs FOR UPDATE locks Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 From: "Simon Riggs" To: "Tom Lane" Cc: "Heikki Linnakangas" , "Alvaro Herrera" , , In-Reply-To: <1128.1164998817@sss.pgh.pa.us> 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> <534.1164994846@sss.pgh.pa.us> <45706A77.8030503@enterprisedb.com> <1128.1164998817@sss.pgh.pa.us> Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 01 Dec 2006 20:46:56 +0000 Message-ID: <1165006016.3778.888.camel@silverbirch.site> MIME-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 20:47:23.0531 (UTC) FILETIME=[E71A45B0:01C71589] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/42 X-Sequence-Number: 94523 On Fri, 2006-12-01 at 13:46 -0500, Tom Lane wrote: > I'm also realizing that a fix along the throw-an-error line is > nontrivial, eg, HeapTupleSatisfiesUpdate would need another return code. Yes, thats starting to get hairy. The fix could easily break something else in another corner of MVCC. > So at this point we are facing three options: > - throw in a large and poorly tested "fix" at the last moment; > - postpone 8.2 until we can think of a real fix, which might > be a major undertaking; > - ship 8.2 with the same behavior 8.0 and 8.1 had. > None of these are very attractive, but I'm starting to think the last > is the least bad. The functionality in this area isn't yet complete anyway; we still have locking in the partitioned table case to consider. It's not that bad just to leave it as is. So last option gets my vote. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com