Re: FOR SHARE vs FOR UPDATE locks

"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