consideration, but
       it can be particularly important in a busy system using Serializable
       transactions.
      </para>
     </listitem>
     <listitem>
      <para>
       Don't put more into a single transaction than needed for integrity
       purposes.
      </para>
     </listitem>
     <listitem>
      <para>
       Don't leave connections dangling <quote>idle in transaction</quote>
       longer than necessary.  The configuration parameter
       <xref linkend="guc-idle-in-transaction-session-timeout"/> may be used to
       automatically disconnect lingering sessions.
      </para>
     </listitem>
     <listitem>
      <para>
       Eliminate explicit locks, <literal>SELECT FOR UPDATE</literal>, and
       <literal>SELECT FOR SHARE</literal> where no longer needed due to the
       protections automatically provided by Serializable transactions.
      </para>
     </listitem>
     <listitem>
      <para>
       When the system is forced to combine multiple page-level predicate
       locks into a single relation-level predicate lock because the predicate
       lock table is short of memory, an increase in the rate of serialization
       failures may occur.  You can avoid this by increasing
       <xref linkend="guc-max-pred-locks-per-transaction"/>,
       <xref linkend="guc-max-pred-locks-per-relation"/>, and/or
       <xref linkend="guc-max-pred-locks-per-page"/>.
      </para>
     </listitem>
     <listitem>
      <para>
       A sequential scan will always necessitate a relation-level predicate
       lock.  This can result in an increased rate of serialization failures.
       It may be helpful to encourage the use of index scans by reducing
       <xref linkend="guc-random-page-cost"/> and/or increasing
       <xref linkend="guc-cpu-tuple-cost"/>.  Be sure to weigh any decrease
       in transaction rollbacks and restarts against any overall change in
       query execution time.
      </para>
     </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>

  <sect1 id="explicit-locking">
   <title>Explicit Locking</title>

   <indexterm>
    <primary>lock</primary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> provides various lock modes
    to control concurrent access to data in tables.  These modes can
    be used for application-controlled locking in situations where
    <acronym>MVCC</acronym> does not give the desired behavior.  Also,
    most <productname>PostgreSQL</productname> commands automatically
    acquire locks of appropriate modes to ensure that referenced
    tables are not dropped or modified in incompatible ways while the
    command executes.  (For example, <command>TRUNCATE</command> cannot safely be
    executed concurrently with other operations on the same table, so it
    obtains an <literal>ACCESS EXCLUSIVE</literal> lock on the table to
    enforce that.)
   </para>

   <para>
    To examine a list of the currently outstanding locks in a database
    server, use the
    <link linkend="view-pg-locks"><structname>pg_locks</structname></link>
    system view. For more information on monitoring the status of the lock
    manager subsystem, refer to <xref linkend="monitoring"/>.
   </para>

  <sect2 id="locking-tables">
   <title>Table-Level Locks</title>

   <indexterm zone="locking-tables">
    <primary>LOCK</primary>
   </indexterm>

   <para>
    The list below shows the available lock modes and the contexts in
    which they are used automatically by
    <productname>PostgreSQL</productname>.