On Sun, Dec 19, 2010 at 9:12 AM, Florian Pflug <fgp@phlo.org> wrote:
>> On Sun, Dec 19, 2010 at 4:02 AM, Florian Pflug <fgp@phlo.org> wrote:
>>> Note that it's sufficient to check if B can see the effects of the
>>> *latest* locker of T. If it can see those, it must also see the
>>> effects of any previous locker. But because of this, B cannot
>>> distinguish different lock strengths on T - even if A locked T
>>> in exclusive mode, some transaction A2 may lock T in shared mode
>>> after A has committed but before B inspects T.
>>
>> This seems to point to a rather serious problem, though. If B sees
>> that the last locker A1 aborted, correctness requires that it roll
>> back B, because there might have been some other transaction A2 which
>> locked locked T and committed before A1 touched it. Implementing that
>> behavior could lead to a lot of spurious rollbacks, but NOT
>> implementing it isn't fully correct.
>
> Certainly seems serios. How on earth did I manage to miss that one, I
> wonder :-(
>
> If only shared locks are invovled, the patch probably works correctly,
> though, since they don't remove all traces of previous lockers, they
> merely add themselves to the multi-xid holding the lock. That'd also
> explain why my concurrency test-suite didn't trip over this. So we may
> only need to do what you propose for exclusive locks.
I'd be willing to bet, without checking, that if the previous shared
locker is no longer running by the time the next one comes along, we
don't create a multixact in the first place. And even if it does,
what about this: exclusive lock, commit, shared lock, abort.
As unhappy as I am with the present behavior, this cure sounds like it
might be worse than the disease.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company