Nicolas Barbier wrote:
>> Quote:
[...]
>>
>> That sounds like it should actually work.
>
> That boils down to 2PL, using a granularity that is somewhere between
> table locks and single-row locks (note that the latter doesn't
> correctly enforce serializability, hence something more coarse which
> also locks not-yet-existing rows is needed).
That's how I understood it too.
> Disadvantages:
>
> 1. Unstable latency: Depending on whether indexes or table scans are
> used (i.e., the plan), other transactions may be blocked for long
> durations or not.
> 2. Unstable susceptibility to deadlocks: Idem; it is possible that
> once the planner starts to use another kind of scans, that your
> transactions start to deadlock.
>
> It seems that the proposed SIREAD method fixes at least (1), because
> there is no additional blocking involved. I am not sure whether the
> serialization failures that it may cause are dependent on the plan
> used. If so, that would be very similar to (2).
Well, I guess that you have to pay somehow for serializability - there
will be more locks and more lock management.
I did not think of that, but it is really unpleasant if your transactions
suddenly start receiving serialization errors because the plan has been
changed. And the thesis says that the tests did not reveal too many
false positives, so maybe it is not that bad.
But maybe that's a price worth paying for serializability?
Yours,
Laurenz Albe