>>> Paul Schlie <sch...@comcast.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers