Skip site navigation (1) Skip section navigation (2)

Re: Problem with pg_upgrade?

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-30 21:35:50
Message-ID: 201103302135.p2ULZo921809@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian 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.
> 
> I wonder if the fact that these people never reported the bug means
> there were doing something odd with their servers.

I just updated the C comment about what we are doing:

     * Using autovacuum=off disables cleanup vacuum and analyze, but
     * freeze vacuums can still happen, so we set
     * autovacuum_freeze_max_age very high.  We assume all datfrozenxid and
     * relfrozen values are less than a gap of 2000000000 from the current
     * xid counter, so autovacuum will not touch them.

-- 
  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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-03-30 21:41:53
Subject: Re: pg_upgrade and PGCLIENTENCODING
Previous:From: Peter EisentrautDate: 2011-03-30 21:30:09
Subject: Re: pg_upgrade and PGCLIENTENCODING

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group