]> granicus.if.org Git - postgresql/commit
Initialize the minimum frozen Xid in vac_update_datfrozenxid using
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 11 Sep 2008 14:01:35 +0000 (14:01 +0000)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Thu, 11 Sep 2008 14:01:35 +0000 (14:01 +0000)
commit2d4ef572b42eb8062f895db441d319bc1b136aeb
treeddbc032edf286b319c0ab35edabf0510849a6b47
parent8208fbb4ce26e08287f2b8ac68e530959880d88e
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/tqual.c