Re: Problem with pg_upgrade?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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 01:49:18
Message-ID: 201103310149.p2V1nIV08361@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-03-31 02:17:41 Re: Problem with pg_upgrade?
Previous Message Robert Haas 2011-03-31 01:37:56 Re: pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE