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

Re: [GENERAL] pg_upgrade problem

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: depesz <depesz(at)depesz(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] pg_upgrade problem
Date: 2011-08-31 17:35:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Alvaro Herrera wrote:
> > > I don't understand the pg_upgrade code here.  It is setting the
> > > datfrozenxid and relfrozenxid values to the latest checkpoint's NextXID,
> > > 
> > >         /* set pg_class.relfrozenxid */
> > >         PQclear(executeQueryOrDie(conn,
> > >                                   "UPDATE   pg_catalog.pg_class "
> > >                                   "SET  relfrozenxid = '%u' "
> > >         /* only heap and TOAST are vacuumed */
> > >                                   "WHERE    relkind IN ('r', 't')",
> > >                                   old_cluster.controldata.chkpnt_nxtxid));
> > > 
> > > but I don't see why this is safe.  I mean, surely the previous
> > > vacuum might have been a lot earlier than that.  Are these values reset
> > > to more correct values (i.e. older ones) later somehow?  My question is,
> > > why isn't the new cluster completely screwed?
> > 
> > Have you looked at my pg_upgrade presentation?
> > 
> >
> I just did, but it doesn't explain this in much detail.  (In any case I
> don't think we should be relying in a PDF presentation to explain the
> inner pg_upgrade details.  I think we should rely more on the
> IMPLEMENTATION file rather than your PDF ... amusingly that file doesn't
> mention the frozenxids.)
> > This query happens after we have done a VACUUM FREEEZE on an empty
> > cluster.
> Oh, so it only affects the databases that initdb created, right?
> The other ones are not even created yet.


> > pg_dump --binary-upgrade will dump out the proper relfrozen xids for
> > every object that gets its file system files copied or linked.
> Okay.  I assume that between the moment you copy the pg_clog files from
> the old server, and the moment you do the UPDATEs on pg_class and
> pg_database, there is no chance for vacuum to run and remove clog
> segments.

Right, we disable it, and had a long discussion about it.  We actually
start the server with:

        "-c autovacuum=off -c autovacuum_freeze_max_age=2000000000",

> Still, it seems to me that this coding makes Min(datfrozenxid) to go
> backwards, and that's bad news.

Yes, it is odd, but I don't see another option.  Remember the problem
with xid wrap-around --- we really are defining two different xid eras,
and have to freeze to make that possible.

> > > I wonder if pg_upgrade shouldn't be doing the conservative thing here,
> > > which AFAICT would be to set all frozenxid values as furthest in the
> > > past as possible (without causing a shutdown-due-to-wraparound, and
> > > maybe without causing autovacuum to enter emergency mode either).
> > 
> > I already get complaints about requiring an "analyze" run after the
> > upgrade --- this would make it much worse.  In fact I have to look into
> > upgrading optimizer statistics someday.
> Why would it make it worse at all?  It doesn't look to me like it
> wouldn't affect in any way.  The only thing it does, is tell the system
> to keep clog segments around.

It will cause excessive vacuum freezing to happen on startup, I assume.

  Bruce Momjian  <bruce(at)momjian(dot)us>

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

In response to

pgsql-hackers by date

Next:From: hubert depesz lubaczewskiDate: 2011-08-31 17:45:51
Subject: Re: [GENERAL] pg_upgrade problem
Previous:From: Alvaro HerreraDate: 2011-08-31 17:31:07
Subject: Re: [GENERAL] pg_upgrade problem

pgsql-general by date

Next:From: hubert depesz lubaczewskiDate: 2011-08-31 17:45:51
Subject: Re: [GENERAL] pg_upgrade problem
Previous:From: John R PierceDate: 2011-08-31 17:32:46
Subject: Re: "invalid input syntax for type bytea"

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