To: "Heikki Linnakangas" <heikki@enterprisedb.com>
cc: "Alvaro Herrera" <alvherre@commandprompt.com>,
	"Simon Riggs" <simon@2ndquadrant.com>, pgsql-hackers@postgreSQL.org
Subject: Re: FOR SHARE vs FOR UPDATE locks 
In-reply-to: <45706A77.8030503@enterprisedb.com> 
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>
Comments: In-reply-to "Heikki Linnakangas" <heikki@enterprisedb.com>
	message dated "Fri, 01 Dec 2006 17:46:31 +0000"
Date: Fri, 01 Dec 2006 12:58:31 -0500
Message-ID: <758.1164995911@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> 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.

Well, there's nothing "arbitrarily chosen" about it, because the lock
shown in the tuple would always be the most senior live subtransaction.
So I don't think your concern above is a real problem.  Nonetheless, the
proposed hack is definitely playing some games with the semantics, and
while we might be able to get away with that for the question of "is this
lock shared or exclusive", it certainly won't do for an actual update.

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

I think it's OK to fix it so that we allow the pre-existing lock to be
held by a subtransaction of the current xact, but not a parent.

			regards, tom lane