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

nodeBitmapHeapscan.c

Blame
    • Alvaro Herrera's avatar
      d53a5668
      Initialize the minimum frozen Xid in vac_update_datfrozenxid using · d53a5668
      Alvaro Herrera authored
      GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not
      depend on the latter being correctly set elsewhere, and while it is more
      expensive, this code path is not performance-critical.  This is a real
      risk for autovacuum, because it can execute whole cycles without doing
      a single vacuum, which would mean that RecentGlobalXmin would stay at its
      initialization value, FirstNormalTransactionId, causing a bogus value to be
      inserted in pg_database.  This bug could explain some recent reports of
      failure to truncate pg_clog.
      
      At the same time, change the initialization of RecentGlobalXmin to
      InvalidTransactionId, and ensure that it's set to something else whenever
      it's going to be used.  Using it as FirstNormalTransactionId in HOT page
      pruning could incur in data loss.  InitPostgres takes care of setting it
      to a valid value, but the extra checks are there to prevent "special"
      backends from behaving in unusual ways.
      
      Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us
      d53a5668
      History
      Initialize the minimum frozen Xid in vac_update_datfrozenxid using
      Alvaro Herrera authored
      GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not
      depend on the latter being correctly set elsewhere, and while it is more
      expensive, this code path is not performance-critical.  This is a real
      risk for autovacuum, because it can execute whole cycles without doing
      a single vacuum, which would mean that RecentGlobalXmin would stay at its
      initialization value, FirstNormalTransactionId, causing a bogus value to be
      inserted in pg_database.  This bug could explain some recent reports of
      failure to truncate pg_clog.
      
      At the same time, change the initialization of RecentGlobalXmin to
      InvalidTransactionId, and ensure that it's set to something else whenever
      it's going to be used.  Using it as FirstNormalTransactionId in HOT page
      pruning could incur in data loss.  InitPostgres takes care of setting it
      to a valid value, but the extra checks are there to prevent "special"
      backends from behaving in unusual ways.
      
      Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us