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.2until 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