On Wed, Mar 30, 2011 at 5:27 PM, Bruce Momjian <bruce@momjian.us> wrote:
> First, I am not sure it is a problem, but based on the IRC reports I
> felt I should ask here for confirmation. Here is a sample pg_dump
> output:
>
> CREATE TABLE sample (
> x integer
> );
>
> -- For binary upgrade, set relfrozenxid.
> UPDATE pg_catalog.pg_class
> SET relfrozenxid = '703'
> WHERE oid = 'sample'::pg_catalog.regclass;
>
> So, we set the cluster xid while we do this schema-only restore. I
> belive it might be possible for autovacuum to run while the schema is
> restored, see an empty table, and set the relfrozenxid to be the current
> xid, when in fact we are about to put a heap file in place of the
> current empty file. I thought the autovacuum_freeze_max_age=2000000000
> would prevent this but now I am not sure. I assumed that since the gap
> between the restored relfrozenxid and the current counter would
> certainly be < 2000000000 that autovacuum would not touch it. It is
> possible these users had drastically modified autovacuum_freeze_max_age
> to cause 3-billion gaps --- again, I have no direct contact with the
> reporters, but I figured being paranoid is a good thing where pg_upgrade
> is involved.
It does seem possible that that could happen, but I'm not sure exactly
what would be causing autovacuum to fire in the first place. It
wouldn't have to be triggered by the anti-wraparound machinery - if
the table appeared to be in need of vacuuming, then we'd vacuum it,
discover that is was empty, and update relfrozenxid. Hmm... could it
fire just because the table has no stats? But if that were the case
you'd think we'd be seeing this more often.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
