method to implement only
   <function>amgetbitmap</function> and not <function>amgettuple</function>, or vice versa,
   if its internal implementation is unsuited to one API or the other.
  </para>

 </sect1>

 <sect1 id="index-locking">
  <title>Index Locking Considerations</title>

  <para>
   Index access methods must handle concurrent updates
   of the index by multiple processes.
   The core <productname>PostgreSQL</productname> system obtains
   <literal>AccessShareLock</literal> on the index during an index scan, and
   <literal>RowExclusiveLock</literal> when updating the index (including plain
   <command>VACUUM</command>).  Since these lock types do not conflict, the access
   method is responsible for handling any fine-grained locking it might need.
   An <literal>ACCESS EXCLUSIVE</literal> lock on the index as a whole will be
   taken only during index creation, destruction, or <command>REINDEX</command>
   (<literal>SHARE UPDATE EXCLUSIVE</literal> is taken instead with
   <literal>CONCURRENTLY</literal>).
  </para>

  <para>
   Building an index type that supports concurrent updates usually requires
   extensive and subtle analysis of the required behavior.  For the b-tree
   and hash index types, you can read about the design decisions involved in
   <filename>src/backend/access/nbtree/README</filename> and
   <filename>src/backend/access/hash/README</filename>.
  </para>

  <para>
   Aside from the index's own internal consistency requirements, concurrent
   updates create issues about consistency between the parent table (the
   <firstterm>heap</firstterm>) and the index.  Because
   <productname>PostgreSQL</productname> separates accesses
   and updates of the heap from those of the index, there are windows in
   which the index might be inconsistent with the heap.  We handle this problem
   with the following rules:

    <itemizedlist>
     <listitem>
      <para>
       A new heap entry is made before making its index entries.  (Therefore
       a concurrent index scan is likely to fail to see the heap entry.
       This is okay because the index reader would be uninterested in an
       uncommitted row anyway.  But see <xref linkend="index-unique-checks"/>.)
      </para>
     </listitem>
     <listitem>
      <para>
       When a heap entry is to be deleted (by <command>VACUUM</command>), all its
       index entries must be removed first.
      </para>
     </listitem>
     <listitem>
      <para>
       An index scan must maintain a pin
       on the index page holding the item last returned by
       <function>amgettuple</function>, and <function>ambulkdelete</function> cannot delete
       entries from pages that are pinned by other backends.  The need
       for this rule is explained below.
      </para>
     </listitem>
    </itemizedlist>

   Without the third rule, it is possible for an index reader to
   see an index entry just before it is removed by <command>VACUUM</command>, and
   then to arrive at the 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