Re: FOR SHARE vs FOR UPDATE locks

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)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