From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem with pg_upgrade? |
Date: | 2011-03-31 02:17:41 |
Message-ID: | 201103310217.p2V2HgB15874@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-03-31 02:46:54 | Re: Replication server timeout patch |
Previous Message | Bruce Momjian | 2011-03-31 01:49:18 | Re: Problem with pg_upgrade? |