begriffs open source - ai-pg/blob - full-docs/html/index-locking.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>63.4. Index Locking Considerations</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="index-scanning.html" title="63.3. Index Scanning" /><link rel="next" href="index-unique-checks.html" title="63.5. Index Uniqueness Checks" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">63.4. Index Locking Considerations</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="index-scanning.html" title="63.3. Index Scanning">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="indexam.html" title="Chapter 63. Index Access Method Interface Definition">Up</a></td><th width="60%" align="center">Chapter 63. Index Access Method Interface Definition</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="index-unique-checks.html" title="63.5. Index Uniqueness Checks">Next</a></td></tr></table><hr /></div><div class="sect1" id="INDEX-LOCKING"><div class="titlepage"><div><div><h2 class="title" style="clear: both">63.4. Index Locking Considerations <a href="#INDEX-LOCKING" class="id_link">#</a></h2></div></div></div><p>
   3    Index access methods must handle concurrent updates
   4    of the index by multiple processes.
   5    The core <span class="productname">PostgreSQL</span> system obtains
   6    <code class="literal">AccessShareLock</code> on the index during an index scan, and
   7    <code class="literal">RowExclusiveLock</code> when updating the index (including plain
   8    <code class="command">VACUUM</code>).  Since these lock types do not conflict, the access
   9    method is responsible for handling any fine-grained locking it might need.
  10    An <code class="literal">ACCESS EXCLUSIVE</code> lock on the index as a whole will be
  11    taken only during index creation, destruction, or <code class="command">REINDEX</code>
  12    (<code class="literal">SHARE UPDATE EXCLUSIVE</code> is taken instead with
  13    <code class="literal">CONCURRENTLY</code>).
  14   </p><p>
  15    Building an index type that supports concurrent updates usually requires
  16    extensive and subtle analysis of the required behavior.  For the b-tree
  17    and hash index types, you can read about the design decisions involved in
  18    <code class="filename">src/backend/access/nbtree/README</code> and
  19    <code class="filename">src/backend/access/hash/README</code>.
  20   </p><p>
  21    Aside from the index's own internal consistency requirements, concurrent
  22    updates create issues about consistency between the parent table (the
  23    <em class="firstterm">heap</em>) and the index.  Because
  24    <span class="productname">PostgreSQL</span> separates accesses
  25    and updates of the heap from those of the index, there are windows in
  26    which the index might be inconsistent with the heap.  We handle this problem
  27    with the following rules:
  28
  29     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
  30        A new heap entry is made before making its index entries.  (Therefore
  31        a concurrent index scan is likely to fail to see the heap entry.
  32        This is okay because the index reader would be uninterested in an
  33        uncommitted row anyway.  But see <a class="xref" href="index-unique-checks.html" title="63.5. Index Uniqueness Checks">Section 63.5</a>.)
  34       </p></li><li class="listitem"><p>
  35        When a heap entry is to be deleted (by <code class="command">VACUUM</code>), all its
  36        index entries must be removed first.
  37       </p></li><li class="listitem"><p>
  38        An index scan must maintain a pin
  39        on the index page holding the item last returned by
  40        <code class="function">amgettuple</code>, and <code class="function">ambulkdelete</code> cannot delete
  41        entries from pages that are pinned by other backends.  The need
  42        for this rule is explained below.
  43       </p></li></ul></div><p>
  44
  45    Without the third rule, it is possible for an index reader to
  46    see an index entry just before it is removed by <code class="command">VACUUM</code>, and
  47    then to arrive at the corresponding heap entry after that was removed by
  48    <code class="command">VACUUM</code>.
  49    This creates no serious problems if that item
  50    number is still unused when the reader reaches it, since an empty
  51    item slot will be ignored by <code class="function">heap_fetch()</code>.  But what if a
  52    third backend has already re-used the item slot for something else?
  53    When using an MVCC-compliant snapshot, there is no problem because
  54    the new occupant of the slot is certain to be too new to pass the
  55    snapshot test.  However, with a non-MVCC-compliant snapshot (such as
  56    <code class="literal">SnapshotAny</code>), it would be possible to accept and return
  57    a row that does not in fact match the scan keys.  We could defend
  58    against this scenario by requiring the scan keys to be rechecked
  59    against the heap row in all cases, but that is too expensive.  Instead,
  60    we use a pin on an index page as a proxy to indicate that the reader
  61    might still be <span class="quote">“<span class="quote">in flight</span>”</span> from the index entry to the matching
  62    heap entry.  Making <code class="function">ambulkdelete</code> block on such a pin ensures
  63    that <code class="command">VACUUM</code> cannot delete the heap entry before the reader
  64    is done with it.  This solution costs little in run time, and adds blocking
  65    overhead only in the rare cases where there actually is a conflict.
  66   </p><p>
  67    This solution requires that index scans be <span class="quote">“<span class="quote">synchronous</span>”</span>: we have
  68    to fetch each heap tuple immediately after scanning the corresponding index
  69    entry.  This is expensive for a number of reasons.  An
  70    <span class="quote">“<span class="quote">asynchronous</span>”</span> scan in which we collect many TIDs from the index,
  71    and only visit the heap tuples sometime later, requires much less index
  72    locking overhead and can allow a more efficient heap access pattern.
  73    Per the above analysis, we must use the synchronous approach for
  74    non-MVCC-compliant snapshots, but an asynchronous scan is workable
  75    for a query using an MVCC snapshot.
  76   </p><p>
  77    In an <code class="function">amgetbitmap</code> index scan, the access method does not
  78    keep an index pin on any of the returned tuples.  Therefore
  79    it is only safe to use such scans with MVCC-compliant snapshots.
  80   </p><p>
  81    When the <code class="structfield">ampredlocks</code> flag is not set, any scan using that
  82    index access method within a serializable transaction will acquire a
  83    nonblocking predicate lock on the full index.  This will generate a
  84    read-write conflict with the insert of any tuple into that index by a
  85    concurrent serializable transaction.  If certain patterns of read-write
  86    conflicts are detected among a set of concurrent serializable
  87    transactions, one of those transactions may be canceled to protect data
  88    integrity.  When the flag is set, it indicates that the index access
  89    method implements finer-grained predicate locking, which will tend to
  90    reduce the frequency of such transaction cancellations.
  91   </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index-scanning.html" title="63.3. Index Scanning">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="indexam.html" title="Chapter 63. Index Access Method Interface Definition">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="index-unique-checks.html" title="63.5. Index Uniqueness Checks">Next</a></td></tr><tr><td width="40%" align="left" valign="top">63.3. Index Scanning </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 63.5. Index Uniqueness Checks</td></tr></table></div></body></html>