OSDN Git Service

Initialize the minimum frozen Xid in vac_update_datfrozenxid using
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 11 Sep 2008 14:01:10 +0000 (14:01 +0000)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 11 Sep 2008 14:01:10 +0000 (14:01 +0000)
commitd53a56687f3d4772d17ffa0013a33231b7163731
tree747aab3bf4ef4fbf741830d2452ad84867329919
parentb8646012d560f3364b0076bb528866f869c3a61e
Initialize the minimum frozen Xid in vac_update_datfrozenxid using
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
src/backend/access/heap/heapam.c
src/backend/access/index/indexam.c
src/backend/commands/vacuum.c
src/backend/executor/nodeBitmapHeapscan.c
src/backend/utils/init/postinit.c
src/backend/utils/time/snapmgr.c