Re: incoherent view of serializable transactions

> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>>>> Paul Schlie <schlie(at)comcast(dot)net> wrote:
>> Sorry if I'm restating the obvious, however I don't understand the
>> confusion, as it seems the standard's definition isn't mysterious;
>> it simply requires that the resulting state from the concurrent
>> execution of transactions (and implicitly any subset) designated to
>> occur at the isolation level SERIALIZABLE be equivalent to SOME
>> LITERALLY SERIAL execution of said transactions.
>
> I think that some of the confusion may result from changes in the
> standard. As far as I can recall, the language requiring that the
> SERIALIZABLE transaction isolation level be truly serializable was not
> in early versions of the standard, and it may be that there is some
> reluctance to concede that a shift in the standard has rendered
> PostgreSQL out of compliance on this point.
>
> As I see it, the discussion on this thread is around recognition of
> the requirements of the current standard within the PostgreSQL
> documentation.
>
> There is a related thread on which I'm attempting to come up with
> documentation to assist those familiar with true serializable behavior
> who are attempting to recognize application coding patterns where the
> differences between that and snapshot isolation are material, with
> tips on how to handle these differences. There seems to be some
> question whether the patterns in which anomalies occur are common
> enough to merit comment.
>
> If you could reference any concise and accessible work on these
> anomalies and practical workarounds in application code, it would be
> much appreciated.

Personally; although compliance may reduce the execution performance of
such so designated transactions, it will correspondingly warrant correct
results, and should be the goal rather than documenting non-conformance;
as those who wish to embed more direct control over transaction evaluation
into their specification to enable their improved concurrent execution
efficiency by utilizing more relaxed evaluation semantics, remain free to
do without penalty. (Simple examples of the risk of non-compliance already
seem sufficiently identified in your example and first reference cited).

Merely documenting that transactions designated to be evaluated at the
isolation level SERIALIZABLE may not yield expected results, as currently
identified, seems sufficient in the short term; and as/if enough interest
develops otherwise, so may an effort to warrant compliance; I suspect.

(as that known to most often be fine, can't be relied upon in practice)