Bruce Momjian wrote: > Bruce Momjian wrote: > > > 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. > > What if we allow autovacuum_max_workers to be set to zero; the current > minimum is one.
I can think of one case where autovacuum_freeze_max_age would be insufficient. If you set autovacuum_freeze_max_age in the old cluster to 2B, and you had a database that was near that limit, the tables created by pg_upgrade's --schema-only restore might create enough new transactions to cause autovacuum to run in freeze mode. While I think it is unlikely that is the cause of the problem report, it is enough for me to discount using autovacuum_freeze_max_age to disable autovacuum freeze. I will work on code to allow autovacuum_max_workers to be set to zero in HEAD and 9.0, and have pg_upgrade us that. I think the maintenance overhead of an invisible variable is too much. -- 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
