thread-index: AccVcKb4iJSuWNzdSPWFeQht2hPrwA==
Message-ID: <45706A77.8030503@enterprisedb.com>
Content-Class: urn:content-classes:message
Importance: normal
Date: Fri, 01 Dec 2006 17:46:31 +0000
From: "Heikki Linnakangas" <heikki@enterprisedb.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060927)
MIME-Version: 1.0
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Alvaro Herrera" <alvherre@commandprompt.com>,
	"Simon Riggs" <simon@2ndquadrant.com>, <pgsql-hackers@postgreSQL.org>
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>
	<45705E9C.2060003@enterprisedb.com> <534.1164994846@sss.pgh.pa.us>
In-Reply-To: <534.1164994846@sss.pgh.pa.us>
Content-Type: text/plain;
	format=flowed;
	charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Actually ... wait a minute.  The proposed hack covers the case of
> SELECT FOR SHARE followed by SELECT FOR UPDATE within a subtransaction.
> But what about SELECT FOR SHARE followed by an actual UPDATE (or DELETE)?
> 
> We certainly don't want to mark the UPDATE/DELETE as having been carried
> out by the upper transaction, but there's no way we can record the
> UPDATE while still remembering the previous share-lock.
> 
> So I think I'm back to the position that we should throw an error here.

Yeah. Even without a real update, I just figured you can't upgrade a 
shared lock held by an arbitrarily chosen parent to an exclusive lock. 
If that subxid aborts, and if any of the parents of that subtransaction 
held the shared lock, that lock would be released incorrectly. Which is 
essentially the same problem we began with.

Let's throw an error for now. We have to come back to this in 8.3, I think.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com