Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 5E7169FA4D6; Tue, 5 Dec 2006 01:48:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 71243-04; Tue, 5 Dec 2006 01:48:37 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 2F8D99FA5B9; Tue, 5 Dec 2006 01:27:06 -0400 (AST) Received: from [10.26.67.79] (72-254-61-58.client.stsn.net [72.254.61.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by noel.decibel.org (Postfix) with ESMTP id 2D77556423; Tue, 5 Dec 2006 05:27:00 +0000 (UTC) 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> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Heikki Linnakangas" , "Alvaro Herrera" , "Simon Riggs" , pgsql-hackers@postgresql.org, pgsql-core@postgresql.org Content-Transfer-Encoding: 7bit From: Jim Nasby Subject: Re: FOR SHARE vs FOR UPDATE locks Date: Sun, 3 Dec 2006 22:44:01 -0800 To: Tom Lane X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.523 tagged_above=0 required=5 tests=AWL, BAYES_20, DATE_IN_PAST_12_24, SPF_PASS X-Spam-Level: X-Archive-Number: 200612/158 X-Sequence-Number: 94638 On Dec 1, 2006, at 10:46 AM, Tom Lane wrote: > If we > do make it throw an error I'm afraid that we will break applications > that aren't having a problem at the moment. What about throwing a warning? Shouldn't break anything, but at least then anyone who's experiencing this and has just gotten lucky so far will have a better idea that it's happening. As for possibly using the in-memory store of multiple CIDs affecting a tuple, could that not work if that store contained enough information to 'rollback' the lock to it's original state when restoring to a savepoint? AFAIK other backends would only need to know what the current lock being held was, they wouldn't need to know the history of it themselves... -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)