>>> 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.
-Kevin