public inbox for [email protected]  
help / color / mirror / Atom feed
From: David G. Johnston <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Add a new table for Transaction Isolation?
Date: Fri, 17 Apr 2015 16:36:40 -0700
Message-ID: <CAKFQuwY5wAL1aFyAEt1ZxBHEZRCduiRpUAAVoH_q5VyaRV4RJQ@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwa5=DaJdjeKEsTZXhm11WW0MmQQcBdXc3rhQUEmHqXo1g@mail.gmail.com>
References: <CAKFQuwYBN-b9QY5mSkimiR9JKomQ56v9UOKBgyGkcYAFk59G0A@mail.gmail.com>
	<[email protected]>
	<CAKFQuwa5=DaJdjeKEsTZXhm11WW0MmQQcBdXc3rhQUEmHqXo1g@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>

A bit of scope creep due to wanting to point out the obvious "RR and SER"
are the same observation on the table.  The main body for SER covers the
fact as well though in a very technical way.

I thought pointing out that examples are on the Wiki would be useful as
well - not everyone would think to go there for additional information.  No
like though - just a pointer to it or the Internet generally.

It is not obvious to me what <table tocentry="1"> means...I suspect 1=yes...

David J.

On Wed, Apr 15, 2015 at 6:26 PM, David G. Johnston <
[email protected]> wrote:

> On Wednesday, April 15, 2015, Bruce Momjian <[email protected]> wrote:
>
>> On Mon, Apr 13, 2015 at 08:00:38PM -0700, David G. Johnston wrote:
>> > http://www.postgresql.org/docs/9.4/static/transaction-iso.html
>> >
>> > Table 13-1 shows the SQL standard isolation levels and what is and is
>> not
>> > guaranteed.  Then the text goes on to explain how our implementation
>> differs
>> > from that table.  Is there any opposition to actually adding a similar
>> table,
>> > 13-2, probably right after the paragraph, with the same columns, three
>> rows,
>> > and the corresponding possible/not-possible cell values?
>>
>> Yes, it does make sense to have a table that properly matches the
>> Postgres implementation.   Should I write a patch or would you like to?
>>
>>
> I'll take a crack at it.
>
> David J.
>

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index f88b16e..5002138 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -100,6 +100,14 @@
     phenomena caused by interactions?)
    </para>
 
+  <para>
+   The concepts covered in this section are
+   presented without examples of the behaviors described.  The internet,
+   including and espcially the <productname>PostgreSQL</productname> Wiki, is
+   an excellent resource to learn more about circumstances under which these
+   data phenomena occur, and what the results look like when they do.
+  </para>
+
    <para>
     The phenomena which are prohibited at various levels are:
 
@@ -150,12 +158,12 @@
     <indexterm>
      <primary>transaction isolation level</primary>
     </indexterm>
-    The four transaction isolation levels and the corresponding
-    behaviors are described in <xref linkend="mvcc-isolevel-table">.
+    The four SQL transaction isolation levels, and their 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>
+     <title><acronym>SQL</acronym> Standard Transaction Isolation Levels</title>
      <tgroup cols="4">
       <thead>
        <row>
@@ -256,6 +264,89 @@
    </para>
 
    <para>
+    The three <productname>PostgreSQL</productname> transaction isolation levels, and their corresponding
+    behaviors, are described in <xref linkend="mvcc-pgsql-isolevel-table">.
+   </para>
+
+    <table tocentry="1" id="mvcc-pgsql-isolevel-table">
+     <title><productname>PostgreSQL</productname> Transaction Isolation Levels</title>
+     <tgroup cols="4">
+      <thead>
+       <row>
+        <entry>
+         Isolation Level
+        </entry>
+        <entry>
+         Dirty Read
+        </entry>
+        <entry>
+         Nonrepeatable Read
+        </entry>
+        <entry>
+         Phantom Read
+        </entry>
+       </row>
+      </thead>
+      <tbody>
+       <row>
+        <entry>
+         Read committed
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Possible
+        </entry>
+        <entry>
+         Possible
+        </entry>
+       </row>
+
+       <row>
+        <entry>
+         Repeatable read
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not Possible
+        </entry>
+       </row>
+
+       <row>
+        <entry>
+         Serializable
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+       </row>
+      </tbody>
+     </tgroup>
+    </table>
+
+   <para>
+    As the table makes clear there is no difference in the potential phenomena
+    at the REPEATABLE READ and SERIALIZABLE transaction isolation levels; but
+    the phenomena listed only pertain to the data seen by the transaction.
+    The difference is that REPEATABLE READ will only serial-fail
+    if two transactions attempt to modify the same record while SERIALIZABLE will 
+    also serial-fail if one transaction modifies a record that another transaction 
+    has only read.
+   </para>
+   
+   <para>
     To set the transaction isolation level of a transaction, use the
     command <xref linkend="sql-set-transaction">.
    </para>


-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs


Attachments:

  [text/plain] mvcc-isolationlevels-v1.diff (3.5K, 3-mvcc-isolationlevels-v1.diff)
  download | inline diff:
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index f88b16e..5002138 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -100,6 +100,14 @@
     phenomena caused by interactions?)
    </para>
 
+  <para>
+   The concepts covered in this section are
+   presented without examples of the behaviors described.  The internet,
+   including and espcially the <productname>PostgreSQL</productname> Wiki, is
+   an excellent resource to learn more about circumstances under which these
+   data phenomena occur, and what the results look like when they do.
+  </para>
+
    <para>
     The phenomena which are prohibited at various levels are:
 
@@ -150,12 +158,12 @@
     <indexterm>
      <primary>transaction isolation level</primary>
     </indexterm>
-    The four transaction isolation levels and the corresponding
-    behaviors are described in <xref linkend="mvcc-isolevel-table">.
+    The four SQL transaction isolation levels, and their 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>
+     <title><acronym>SQL</acronym> Standard Transaction Isolation Levels</title>
      <tgroup cols="4">
       <thead>
        <row>
@@ -256,6 +264,89 @@
    </para>
 
    <para>
+    The three <productname>PostgreSQL</productname> transaction isolation levels, and their corresponding
+    behaviors, are described in <xref linkend="mvcc-pgsql-isolevel-table">.
+   </para>
+
+    <table tocentry="1" id="mvcc-pgsql-isolevel-table">
+     <title><productname>PostgreSQL</productname> Transaction Isolation Levels</title>
+     <tgroup cols="4">
+      <thead>
+       <row>
+        <entry>
+         Isolation Level
+        </entry>
+        <entry>
+         Dirty Read
+        </entry>
+        <entry>
+         Nonrepeatable Read
+        </entry>
+        <entry>
+         Phantom Read
+        </entry>
+       </row>
+      </thead>
+      <tbody>
+       <row>
+        <entry>
+         Read committed
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Possible
+        </entry>
+        <entry>
+         Possible
+        </entry>
+       </row>
+
+       <row>
+        <entry>
+         Repeatable read
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not Possible
+        </entry>
+       </row>
+
+       <row>
+        <entry>
+         Serializable
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+        <entry>
+         Not possible
+        </entry>
+       </row>
+      </tbody>
+     </tgroup>
+    </table>
+
+   <para>
+    As the table makes clear there is no difference in the potential phenomena
+    at the REPEATABLE READ and SERIALIZABLE transaction isolation levels; but
+    the phenomena listed only pertain to the data seen by the transaction.
+    The difference is that REPEATABLE READ will only serial-fail
+    if two transactions attempt to modify the same record while SERIALIZABLE will 
+    also serial-fail if one transaction modifies a record that another transaction 
+    has only read.
+   </para>
+   
+   <para>
     To set the transaction isolation level of a transaction, use the
     command <xref linkend="sql-set-transaction">.
    </para>


view thread (23+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Add a new table for Transaction Isolation?
  In-Reply-To: <CAKFQuwY5wAL1aFyAEt1ZxBHEZRCduiRpUAAVoH_q5VyaRV4RJQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox