Doc: Add references for SI and SSI.

Our documentation failed to point out that REPEATABLE READ is really
snapshot isolation, which might be important to some users.  Point to
the standard reference paper for this complicated topic.

Likewise, add a reference to the VLDB paper about PostgreSQL SSI, for
technical information about our SSI implementation and how it compares
to S2PL.

While here, add a note about catalog access using a lower isolation
level, per recent user complaint.

Back-patch to all releases.

Reported-by: Kyle Kingsbury <aphyr@jepsen.io>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Peter Geoghegan <pg@bowt.ie>
Reviewed-by: Tatsuo Ishii <ishii@sraoss.co.jp>
Discussion: https://postgr.es/m/db7b729d-0226-d162-a126-8a8ab2dc4443%40jepsen.io
Discussion: https://postgr.es/m/16454-9408996bb1750faf%40postgresql.org

Author: macdice

doc/src/sgml/biblio.sgml

@@ -230,6 +230,64 @@ ssimkovi@ag.or.at
   <bibliodiv>
    <title>Proceedings and Articles</title>
 
+   <biblioentry id="ports12">
+    <biblioset relation="article">
+     <title><ulink url="https://arxiv.org/pdf/1208.4179">Serializable Snapshot Isolation in PostgreSQL</ulink></title>
+     <authorgroup>
+      <author>
+       <firstname>D.</firstname>
+       <surname>Ports</surname>
+      </author>
+      <author>
+       <firstname>K.</firstname>
+       <surname>Grittner</surname>
+      </author>
+     </authorgroup>
+    </biblioset>
+    <confgroup>
+     <conftitle>VLDB Conference</conftitle>
+     <confdates>August 2012</confdates>
+     <address>Istanbul, Turkey</address>
+    </confgroup>
+   </biblioentry>
+
+   <biblioentry id="berenson95">
+    <biblioset relation="article">
+     <title><ulink url="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf">A Critique of ANSI SQL Isolation Levels</ulink></title>
+     <authorgroup>
+      <author>
+       <firstname>H.</firstname>
+       <surname>Berenson</surname>
+      </author>
+      <author>
+       <firstname>P.</firstname>
+       <surname>Bernstein</surname>
+      </author>
+      <author>
+       <firstname>J.</firstname>
+       <surname>Gray</surname>
+      </author>
+      <author>
+       <firstname>J.</firstname>
+       <surname>Melton</surname>
+      </author>
+      <author>
+       <firstname>E.</firstname>
+       <surname>O'Neil</surname>
+      </author>
+      <author>
+       <firstname>P.</firstname>
+       <surname>O'Neil</surname>
+      </author>
+     </authorgroup>
+    </biblioset>
+    <confgroup>
+     <conftitle>ACM-SIGMOD Conference on Management of Data</conftitle>
+     <confdates>June 1995</confdates>
+     <address>San Jose, California</address>
+    </confgroup>
+   </biblioentry>
+
    <biblioentry id="olson93">
     <title>Partial indexing in POSTGRES: research project</title>
     <authorgroup>

doc/src/sgml/mvcc.sgml

@@ -535,6 +535,20 @@ ERROR:  could not serialize access due to concurrent update
     of explicit locks to block conflicting transactions.
    </para>
 
+   <para>
+    The Repeatable Read isolation level is implemented using a technique
+    known in academic database literature and in some other database products
+    as <firstterm>Snapshot Isolation</firstterm>.  Differences in behavior
+    and performance may be observed when compared with systems that use a
+    traditional locking technique that reduces concurrency.  Some other
+    systems may even offer Repeatable Read and Snapshot Isolation as distinct
+    isolation levels with different behavior.  The permitted phenomena that
+    distinguish the two techniques were not formalized by database researchers
+    until after the SQL standard was developed, and are outside the scope of
+    this manual.  For a full treatment, please see
+    <xref linkend="berenson95"/>.
+   </para>
+
    <note>
     <para>
      Prior to <productname>PostgreSQL</productname> version 9.1, a request
@@ -783,6 +797,15 @@ ERROR:  could not serialize access due to read/write dependencies among transact
      </listitem>
     </itemizedlist>
    </para>
+
+   <para>
+    The Serializable isolation level is implemented using a technique known
+    in academic database literature as Serializable Snapshot Isolation, which
+    builds on Snapshot Isolation by adding checks for serialization anomalies.
+    Some differences in behavior and performance may be observed when compared
+    with other systems that use a traditional locking technique.  Please see
+    <xref linkend="ports12"/> for detailed information.
+   </para>
   </sect2>
  </sect1>
 
@@ -1726,6 +1749,16 @@ SELECT pg_advisory_lock(q.id) FROM
     see a transient state that is inconsistent with any serial execution
     of the transactions on the master.
    </para>
+
+   <para>
+    Internal access to the system catalogs is not done using the isolation
+    level of the current transaction.  This means that newly created database
+    objects such as tables are visible to concurrent Repeatable Read and
+    Serializable transactions, even though the rows they contain are not.  In
+    contrast, queries that explicitly examine the system catalogs don't see
+    rows representing concurrently created database objects, in the higher
+    isolation levels.
+   </para>
   </sect1>
 
   <sect1 id="locking-indexes">