Re: User-facing aspects of serializable transactions

Kevin Grittner wrote:
>> 1. implementation of the paper's technique sans predicate locking,
>> that would avoid more serialization anomalies but not all?
>
> I saw that as a step along the way to support for fully serializable
> transactions. If covered by a "migration path" GUC which defaulted to
> current behavior, it would allow testing of all of the code except the
> predicate lock tracking (before the predicate locking code was
> created), in order to give proof of concept, check performance impact
> of that part of the code, etc. I wasn't thinking that it would be a
> useful long-term option without the addition of the predicate locks.

I cannot prove it, but I have a feeling that the impact on
performance and concurrency will be considerably higher for an
implementation with predicate locks. Every WHERE-clause in a SELECT
will add one or more checks for each concurrent writer.

So while I think it is a good idea to approach full serializability
in a step-by-step approach, it would be wise to consider the possibility
that we will not reach the goal (because implementing predicate locks
might be too difficult or the result perform too badly).

So any intermediate step should be useful in itself, unless we are
ready to rip out the whole thing again.

What would be the useful intermediate steps in this case?

From the user perspective, will an implementation of the paper's
approach as an intermediate step provide a useful and understandable
isolation level?

Yours,
Laurenz Albe