Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 54D159FA178 for ; Fri, 1 Dec 2006 11:45:15 -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 21198-07 for ; Fri, 1 Dec 2006 11:45:06 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from smxsat1.smxs.net (smxsat1.smxs.net [213.150.10.1]) by postgresql.org (Postfix) with ESMTP id 6A4019FA12B for ; Fri, 1 Dec 2006 11:45:05 -0400 (AST) Received: from m01x3.s-mxs.net [10.3.55.203] by smxsat1.smxs.net with XWall v3.38g. ; Fri, 1 Dec 2006 16:45:09 +0100 Received: from m0102.s-mxs.net [10.3.55.2] by m01x3.s-mxs.net with XWall v3.38g. ; Fri, 1 Dec 2006 16:45:03 +0100 Received: from m0143.s-mxs.net ([10.252.53.143]) by m0102.s-mxs.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 16:45:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: FOR SHARE vs FOR UPDATE locks Date: Fri, 1 Dec 2006 16:45:00 +0100 Message-ID: In-Reply-To: <15834.1164985926@sss.pgh.pa.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HACKERS] FOR SHARE vs FOR UPDATE locks Thread-Index: AccVWygRcLqcRo1pQt2QrykqvnjokwAA6Lmw From: "Zeugswetter Andreas ADI SD" To: "Tom Lane" , "Alvaro Herrera" Cc: "Simon Riggs" , X-OriginalArrivalTime: 01 Dec 2006 15:45:02.0408 (UTC) FILETIME=[AA269480:01C7155F] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/19 X-Sequence-Number: 94500 > > I'm not sure we can use the simple "raise an ERROR" answer though, > > because for users that would be a regression. >=20 > 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. fwiw, I think that is good. Andreas