Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 8B17E9FA231; Fri, 1 Dec 2006 14:53:18 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 59025-09; Fri, 1 Dec 2006 14:53:05 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by postgresql.org (Postfix) with ESMTP id D8F799FA12B; Fri, 1 Dec 2006 14:53:06 -0400 (AST) X-EthosMedia-Virus-Scanned: no infections found Received: from [64.81.245.111] (account josh@agliodbs.com HELO [192.168.1.27]) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 10755506; Fri, 01 Dec 2006 10:56:47 -0800 From: Josh Berkus Reply-To: josh@agliodbs.com Organization: Aglio Database Solutions To: pgsql-core@postgresql.org Subject: Re: [CORE] FOR SHARE vs FOR UPDATE locks Date: Fri, 1 Dec 2006 10:55:05 -0800 User-Agent: KMail/1.8 Cc: Tom Lane , "Heikki Linnakangas" , "Alvaro Herrera" , "Simon Riggs" , pgsql-hackers@postgresql.org References: <1144.1164924373@sss.pgh.pa.us> <45706A77.8030503@enterprisedb.com> <1128.1164998817@sss.pgh.pa.us> In-Reply-To: <1128.1164998817@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612011055.06368.josh@agliodbs.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/34 X-Sequence-Number: 94515 Tom, > So at this point we are facing three options: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- throw in a large and po= orly tested "fix" at the last moment; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- postpone 8.2 until we c= an think of a real fix, which might > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0be a major underta= king; > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0- 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. Yes. If it was earlier in the beta cycle I'd say no, but frankly this=20 behavior has existed for two years without examples of real-life data=20 loss. Further, the TPC tests, which are supposed to give ACID properties=20 a workout, would not break this, so the industry doesn't consider it very=20 important either. So, I think it needs to go on the list for 8.2.1 or 8.3 (depending on what= =20 changes the fix requires) but I don't think we should hold up the release. As PR maven, though, you know I'm biased about the release date. I would suggest a last-minute doc patch documenting the behavior and=20 suggesting that locks should always be declared in the outer transaction=20 prior to any savepoints. =2D-=20 =2D-Josh Josh Berkus PostgreSQL @ Sun San Francisco