<!-- doc/src/sgml/mvcc.sgml -->

 <chapter id="mvcc">
  <title>Concurrency Control</title>

  <indexterm>
   <primary>concurrency</primary>
  </indexterm>

  <para>
   This chapter describes the behavior of the
   <productname>PostgreSQL</productname> database system when two or
   more sessions try to access the same data at the same time.  The
   goals in that situation are to allow efficient access for all
   sessions while maintaining strict data integrity.  Every developer
   of database applications should be familiar with the topics covered
   in this chapter.
  </para>

  <sect1 id="mvcc-intro">
   <title>Introduction</title>

   <indexterm>
    <primary>Multiversion Concurrency Control</primary>
   </indexterm>

   <indexterm>
    <primary>MVCC</primary>
   </indexterm>

   <indexterm>
    <primary>Serializable Snapshot Isolation</primary>
   </indexterm>

   <indexterm>
    <primary>SSI</primary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> provides a rich set of tools
    for developers to manage concurrent access to data.  Internally,
    data consistency is maintained by using a multiversion
    model (Multiversion Concurrency Control, <acronym>MVCC</acronym>).
    This means that each SQL statement sees
    a snapshot of data (a <firstterm>database version</firstterm>)
    as it was some
    time ago, regardless of the current state of the underlying data.
    This prevents statements from viewing inconsistent data produced
    by concurrent transactions performing updates on the same
    data rows, providing <firstterm>transaction isolation</firstterm>
    for each database session.  <acronym>MVCC</acronym>, by eschewing
    the locking methodologies of traditional database systems,
    minimizes lock contention in order to allow for reasonable
    performance in multiuser environments.
   </para>

   <para>
    The main advantage of using the <acronym>MVCC</acronym> model of
    concurrency control rather than locking is that in
    <acronym>MVCC</acronym> locks acquired for querying (reading) data
    do not conflict with locks acquired for writing data, and so
    reading never blocks writing and writing never blocks reading.
    <productname>PostgreSQL</productname> maintains this guarantee
    even when providing the strictest level of transaction
    isolation through the use of an innovative <firstterm>Serializable
    Snapshot Isolation</firstterm> (<acronym>SSI</acronym>) level.
   </para>

   <para>
    Table- and row-level locking facilities are also available in
    <productname>PostgreSQL</productname> for applications which don't
    generally need full transaction isolation and prefer to explicitly
    manage particular points of conflict.  However, proper
    use of <acronym>MVCC</acronym> will generally provide better
    performance than locks.  In addition, application-defined advisory
    locks provide a mechanism for acquiring locks that are not tied
    to a single transaction.
   </para>
  </sect1>

  <sect1 id="transaction-iso">
   <title>Transaction Isolation</title>

   <indexterm>
    <primary>transaction isolation</primary>
   </indexterm>

   <para>
    The <acronym>SQL</acronym> standard defines four levels of
    transaction isolation.  The most strict is Serializable,
    which is defined by the standard in a paragraph which says that any
    concurrent execution of a set of Serializable transactions is guaranteed
    to produce the same effect as running them one at a time in some order.
    The other three levels are defined in terms of phenomena, resulting from
    interaction between concurrent transactions, which must not occur at
    each level.  The standard notes that due to the definition of
    Serializable, none of these phenomena are possible at that level.  (This
    is hardly surprising -- if the effect of the transactions must be
    consistent with having been run one at a time, how could you see any
    phenomena caused by interactions?)