Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

bootstrap.c

  • Tom Lane's avatar
    8c19977e
    Avoid changing an index's indcheckxmin horizon during REINDEX. · 8c19977e
    Tom Lane authored
    There can never be a need to push the indcheckxmin horizon forward, since
    any HOT chains that are actually broken with respect to the index must
    pre-date its original creation.  So we can just avoid changing pg_index
    altogether during a REINDEX operation.
    
    This offers a cleaner solution than my previous patch for the problem
    found a few days ago that we mustn't try to update pg_index while we are
    reindexing it.  System catalog indexes will always be created with
    indcheckxmin = false during initdb, and with this modified code we should
    never try to change their pg_index entries.  This avoids special-casing
    system catalogs as the former patch did, and should provide a performance
    benefit for many cases where REINDEX formerly caused an index to be
    considered unusable for a short time.
    
    Back-patch to 8.3 to cover all versions containing HOT.  Note that this
    patch changes the API for index_build(), but I believe it is unlikely that
    any add-on code is calling that directly.
    8c19977e
    History
    Avoid changing an index's indcheckxmin horizon during REINDEX.
    Tom Lane authored
    There can never be a need to push the indcheckxmin horizon forward, since
    any HOT chains that are actually broken with respect to the index must
    pre-date its original creation.  So we can just avoid changing pg_index
    altogether during a REINDEX operation.
    
    This offers a cleaner solution than my previous patch for the problem
    found a few days ago that we mustn't try to update pg_index while we are
    reindexing it.  System catalog indexes will always be created with
    indcheckxmin = false during initdb, and with this modified code we should
    never try to change their pg_index entries.  This avoids special-casing
    system catalogs as the former patch did, and should provide a performance
    benefit for many cases where REINDEX formerly caused an index to be
    considered unusable for a short time.
    
    Back-patch to 8.3 to cover all versions containing HOT.  Note that this
    patch changes the API for index_build(), but I believe it is unlikely that
    any add-on code is calling that directly.