corresponding heap entry after that was removed by
   <command>VACUUM</command>.
   This creates no serious problems if that item
   number is still unused when the reader reaches it, since an empty
   item slot will be ignored by <function>heap_fetch()</function>.  But what if a
   third backend has already re-used the item slot for something else?
   When using an MVCC-compliant snapshot, there is no problem because
   the new occupant of the slot is certain to be too new to pass the
   snapshot test.  However, with a non-MVCC-compliant snapshot (such as
   <literal>SnapshotAny</literal>), it would be possible to accept and return
   a row that does not in fact match the scan keys.  We could defend
   against this scenario by requiring the scan keys to be rechecked
   against the heap row in all cases, but that is too expensive.  Instead,
   we use a pin on an index page as a proxy to indicate that the reader
   might still be <quote>in flight</quote> from the index entry to the matching
   heap entry.  Making <function>ambulkdelete</function> block on such a pin ensures
   that <command>VACUUM</command> cannot delete the heap entry before the reader
   is done with it.  This solution costs little in run time, and adds blocking
   overhead only in the rare cases where there actually is a conflict.
  </para>

  <para>
   This solution requires that index scans be <quote>synchronous</quote>: we have
   to fetch each heap tuple immediately after scanning the corresponding index
   entry.  This is expensive for a number of reasons.  An
   <quote>asynchronous</quote> scan in which we collect many TIDs from the index,
   and only visit the heap tuples sometime later, requires much less index
   locking overhead and can allow a more efficient heap access pattern.
   Per the above analysis, we must use the synchronous approach for
   non-MVCC-compliant snapshots, but an asynchronous scan is workable
   for a query using an MVCC snapshot.
  </para>

  <para>
   In an <function>amgetbitmap</function> index scan, the access method does not
   keep an index pin on any of the returned tuples.  Therefore
   it is only safe to use such scans with MVCC-compliant snapshots.
  </para>

  <para>
   When the <structfield>ampredlocks</structfield> flag is not set, any scan using that
   index access method within a serializable transaction will acquire a
   nonblocking predicate lock on the full index.  This will generate a
   read-write conflict with the insert of any tuple into that index by a
   concurrent serializable transaction.  If certain patterns of read-write
   conflicts are detected among a set of concurrent serializable
   transactions, one of those transactions may be canceled to protect data
   integrity.  When the flag is set, it indicates that the index access
   method implements finer-grained predicate locking, which will tend to
   reduce the frequency of such transaction cancellations.
  </para>

 </sect1>

 <sect1 id="index-unique-checks">
  <title>Index Uniqueness Checks</title>

  <para>
   <productname>PostgreSQL</productname> enforces SQL uniqueness constraints
   using <firstterm>unique indexes</firstterm>, which are indexes that disallow
   multiple entries with identical keys.  An access method that supports this
   feature sets <structfield>amcanunique</structfield> true.
   (At present, only b-tree supports it.)  Columns listed in the
   <literal>INCLUDE</literal> clause are not considered when enforcing
   uniqueness.
  </para>

  <para>
   Because of MVCC, it is always necessary to allow duplicate entries to
   exist physically in an index: the entries might refer to successive
   versions of a single logical row.  The behavior we actually want to
   enforce is that no MVCC snapshot could include two rows with equal
   index keys.  This breaks down into the following cases that must be
   checked when inserting a new row into a unique index:

    <itemizedlist>
     <listitem>
      <para>
       If a conflicting