To: "Heikki Linnakangas" <heikki@enterprisedb.com>
cc: "Alvaro Herrera" <alvherre@commandprompt.com>,
	"Simon Riggs" <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org,
	pgsql-core@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 13:46:57 -0500
Message-ID: <1128.1164998817@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:
> Let's throw an error for now. We have to come back to this in 8.3, I think.

After further thought I think we should also seriously consider plan C:
do nothing for now.  We now realize that there have been related bugs
since 8.0, namely that

	begin;
	select some rows for update;
	savepoint x;
	update the same rows;
	rollback to x;

leaves the tuple(s) not locked.  The lack of complaints about this from
the field suggests that this isn't a huge problem in practice.  If we
do make it throw an error I'm afraid that we will break applications
that aren't having a problem at the moment.

I'm also realizing that a fix along the throw-an-error line is
nontrivial, eg, HeapTupleSatisfiesUpdate would need another return code.

So at this point we are facing three options:
	- throw in a large and poorly tested "fix" at the last moment;
	- postpone 8.2 until we can think of a real fix, which might
	  be a major undertaking;
	- 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.

			regards, tom lane