"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
