Re: Patch for pg_upgrade to turn off autovacuum

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Alvaro Herrera <alvherre@commandprompt.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-04-22T21:30:41Z
Lists: pgsql-hackers

Attachments

Bruce Momjian wrote:
> > > Well, consider that this also locks out non-super users so I figured it
> > > would be good to run the old and new in the same binary upgrade mode.
> > > Again, we can do just the new cluster for 9.1.   I can also control the
> > > behavior based on the catalog version number, which seems the most
> > > logical.
> > 
> > I think you are over-engineering this. Just use it for the new cluster
> > only, full stop, and you'll be right as rain.
> 
> 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.
> 
> FYI, the existing code already doesn't allow autovacuum to run on the old
> or new cluster by setting autovacuum off and autovacuum_freeze_max_age
> very high, so this is not a behavior change --- just a more formalized
> way of turning off autovacuum.
> 
> The attached patch uses catalog version to test;  we use catalog version
> checking already for tablespace subdirectories.

OK, thinking even more, it seems I have to keep the old vacuum disable
flag for pre-9.1 old clusters.  This new patch does that.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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