Robert Haas wrote: > > 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.
Well, autovacuum=off, so it should only run in freeze mode, and I can't see how that could happen. I am thinking I have to study autovacuum.c. I wonder if datfrozenxid could be incremented because the database is originally empty. It would just need to scan pg_class, not actually vacuum anything. I wonder if we do that. The bottom line is I am hanging too much on autovacuum_freeze_max_age causing autovacuum to do nothing. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
