On Fri, Apr 24, 2015 at 08:40:40PM +0000, Kevin Grittner wrote:
> And, for reasons given above, I really question whether such a
> table doesn't do more harm than good. Even those citing the paper
> by Berenson, et al., often miss the text in *that* paper about what
> the actual definition of serializable transactions in the standard
> is, and instead focus on the quick-to-read tables of how the
> misinterpretation of serializable transactions based on the
> standard's table of phenomena (which the paper dubs "ANOMALY
> SERIALIZABLE") differs from truly serializable behavior.
>
> People do love tables like this, which makes providing them
> tempting; but when a short, clean table is available they often
> seem less inclined to take the trouble to read the real information
> the table summarizes -- and they come away with distorted and
> incorrect ideas about the subject matter.
I don't think we can abandon the table --- people have enough trouble
figuring this out, including me, and without the table, it will be even
harder.
What I have done is to add two rows and one column to the table, and
changed the surrounding text to more clearly reference the table. You
can see the output here, and the SGML patch is attached:
http://momjian.us/expire/transaction-iso.html
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
new file mode 100644
index f88b16e..3120e1f
*** a/doc/src/sgml/mvcc.sgml
--- b/doc/src/sgml/mvcc.sgml
***************
*** 150,162 ****
<indexterm>
<primary>transaction isolation level</primary>
</indexterm>
! The four transaction isolation levels and the corresponding
! behaviors are described in <xref linkend="mvcc-isolevel-table">.
</para>
<table tocentry="1" id="mvcc-isolevel-table">
! <title>Standard <acronym>SQL</acronym> Transaction Isolation Levels</title>
! <tgroup cols="4">
<thead>
<row>
<entry>
--- 150,162 ----
<indexterm>
<primary>transaction isolation level</primary>
</indexterm>
! The SQL standard and PostgreSQL-implemented transaction isolation levels
! are described in <xref linkend="mvcc-isolevel-table">.
</para>
<table tocentry="1" id="mvcc-isolevel-table">
! <title>Transaction Isolation Levels</title>
! <tgroup cols="5">
<thead>
<row>
<entry>
***************
*** 171,182 ****
<entry>
Phantom Read
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
! Read uncommitted
</entry>
<entry>
Possible
--- 171,206 ----
<entry>
Phantom Read
</entry>
+ <entry>
+ Serialization Anomalies
+ </entry>
</row>
</thead>
<tbody>
<row>
<entry>
! Read uncommitted (SQL Standard)
! </entry>
! <entry>
! Possible
! </entry>
! <entry>
! Possible
! </entry>
! <entry>
! Possible
! </entry>
! <entry>
! Possible
! </entry>
! </row>
!
! <row>
! <entry>
! Read uncommitted (PostgreSQL)
! </entry>
! <entry>
! Not possible
</entry>
<entry>
Possible
***************
*** 202,212 ****
<entry>
Possible
</entry>
</row>
<row>
<entry>
! Repeatable read
</entry>
<entry>
Not possible
--- 226,260 ----
<entry>
Possible
</entry>
+ <entry>
+ Possible
+ </entry>
</row>
<row>
<entry>
! Repeatable read (SQL Standard)
! </entry>
! <entry>
! Not possible
! </entry>
! <entry>
! Not possible
! </entry>
! <entry>
! Possible
! </entry>
! <entry>
! Possible
! </entry>
! </row>
!
! <row>
! <entry>
! Repeatable read (PostgreSQL)
! </entry>
! <entry>
! Not possible
</entry>
<entry>
Not possible
***************
*** 232,258 ****
<entry>
Not possible
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
! In <productname>PostgreSQL</productname>, you can request any of the
! four standard transaction isolation levels. But internally, there are
! only three distinct isolation levels, which correspond to the levels Read
! Committed, Repeatable Read, and Serializable. When you select the level Read
! Uncommitted you really get Read Committed, and phantom reads are not possible
! in the <productname>PostgreSQL</productname> implementation of Repeatable
! Read, so the actual
! isolation level might be stricter than what you select. This is
! permitted by the SQL standard: the four isolation levels only
! define which phenomena must not happen, they do not define which
! phenomena must happen. The reason that <productname>PostgreSQL</>
! only provides three isolation levels is that this is the only
! sensible way to map the standard isolation levels to the multiversion
! concurrency control architecture. The behavior of the available
! isolation levels is detailed in the following subsections.
</para>
<para>
--- 280,309 ----
<entry>
Not possible
</entry>
+ <entry>
+ Not possible
+ </entry>
</row>
</tbody>
</tgroup>
</table>
<para>
! In <productname>PostgreSQL</productname>, you can request any of
! the four standard transaction isolation levels, but internally only
! three distinct isolation levels are implemented, i.e. PostgreSQL's
! Read Uncommitted mode behaves like Read Committed. This is because
! it is the only sensible way to map the standard isolation levels to
! PostgreSQL's multiversion concurrency control architecture.
! </para>
!
! <para>
! The table also shows that PostgreSQL's Repeatable Read implementation
! does not allow phantom reads. Stricter behavior is permitted by the
! SQL standard: the four isolation levels only define which phenomena
! must not happen, not which phenomena <emphasis>must</> happen.
! The behavior of the available isolation levels is detailed in the
! following subsections.
</para>
<para>
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
