Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 61BC39FA178 for ; Fri, 1 Dec 2006 12:56:08 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 58128-02 for ; Fri, 1 Dec 2006 12:56:02 -0400 (AST) X-Greylist: domain 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 648099FA173 for ; Fri, 1 Dec 2006 12:56:01 -0400 (AST) thread-index: AccVaZZX1RmvWRpiQS23VDycH5Ucrw== Received: from [192.168.0.22] ([62.232.55.118]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 11:56:03 -0500 Message-ID: <45705E9C.2060003@enterprisedb.com> Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Date: Fri, 01 Dec 2006 16:55:56 +0000 From: "Heikki Linnakangas" User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: "Tom Lane" Cc: "Alvaro Herrera" , "Simon Riggs" , Subject: Re: FOR SHARE vs FOR UPDATE locks 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> In-Reply-To: <15834.1164985926@sss.pgh.pa.us> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 16:56:03.0718 (UTC) FILETIME=[9616E260:01C71569] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/21 X-Sequence-Number: 94502 Tom Lane wrote: > Alvaro Herrera writes: >> I'm not sure we can use the simple "raise an ERROR" answer though, >> because for users that would be a regression. > > I've reconsidered the idea of upgrading the outer xact's shared lock to > exclusive: at first I thought that would be hard to implement correctly, > but now I realize it's easy. Just re-use the XID that's in the multixact > as the one to store as the exclusive locker, instead of storing our > current subxact XID. In some cases this will be a subcommitted XID of > the current subxact or a parent, but the locking semantics are the same, > and even though we think such an XID is finished everyone else will see > it as still live so the appearance of its XID in an XMAX field shouldn't > be an issue. That way, the lock won't be downgraded back to a shared lock on "rollback to savepoint", right? Though it's still better than throwing an error, I think. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com