Initialize the minimum frozen Xid in vac_update_datfrozenxid using
authorAlvaro Herrera <[email protected]>
Thu, 11 Sep 2008 14:01:16 +0000 (14:01 +0000)
committerAlvaro Herrera <[email protected]>
Thu, 11 Sep 2008 14:01:16 +0000 (14:01 +0000)
commitaec23022449297e5b390300581b3f322fab5ba6a
treec9b8aba6f36c0938fe545b0ec9873de6891bba4b
parent46707eba25b57d0f1d8a1e96d504806a051bc87a
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/commands/vacuum.c
src/backend/utils/init/postinit.c