Re: Patch for pg_upgrade to turn off autovacuum - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Patch for pg_upgrade to turn off autovacuum
Date
Msg-id 201104222134.p3MLY8g22450@momjian.us
Whole thread Raw
In response to Re: Patch for pg_upgrade to turn off autovacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Patch for pg_upgrade to turn off autovacuum  (Jeff Davis <pgsql@j-davis.com>)
Re: Patch for pg_upgrade to turn off autovacuum  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I thought some more about this and I don't want autovacuum to run on the
> > old server.  This is because pg_dumpall --binary-upgrade --schema-only
> > grabs the datfrozenxid for all the databases at the start, then connects
> > to each database to gets the relfrozenxids.  I don't want to risk any
> > advancement of either of those during the pg_dumpall run.
> 
> Why?  It doesn't really matter --- if you grab a value that is older
> than the latest, it's still valid.  As Robert said, you're
> over-engineering this, and thereby introducing potential failure modes,
> for no gain.

Uh, I am kind of paranoid about pg_upgrade because it is trying to do
something Postgres was never designed to do.  I am a little worried that
we would be assuming that pg_dumpall always does the datfrozenxid first
and if we ever did it last we would have relfrozenxids before the
datfrozenxid.  I am worried if we don't prevent autovacuum on the old
server that pg_upgrade will be more fragile to changes in other parts of
the system.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Patch for pg_upgrade to turn off autovacuum
Next
From: Merlin Moncure
Date:
Subject: Re: "stored procedures"