Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Robert Haas wrote:
> > > On Thu, Mar 31, 2011 at 12:11 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > > > Robert Haas wrote:
> > > >> On Thu, Mar 31, 2011 at 11:32 AM, Heikki Linnakangas
> > > >> <heikki.linnakangas@enterprisedb.com> wrote:
> > > >> >> ?I think the maintenance
> > > >> >> overhead of an invisible variable is too much.
> > > >> >
> > > >> > A simple GUC or command-line switch isn't much code.
> > > >>
> > > >> I like the idea of a command-line switch.
> > > >
> > > > If you want to do that you should gereralize it as --binary-upgrade in
> > > > case we have other needs for it.
> > >
> > > Yeah. Or we could do a binary_upgrade GUC which has the effect of
> > > forcibly suppressing autovacuum, and maybe other things later. I
> > > think that's a lot less hazardous than fiddling with the autovacuum
> > > GUC.
> >
> > I like the idea of a command-line flag because it forces everything to
> > be affected, and cannot be turned on and off in sessions --- if you are
> > doing a binary upgrade, locked-down is good. :-)
>
> The attached patch adds a new postmaster/postgres binary upgrade mode
> (-b) which disables autovacuum, allows only super-user connections, and
> prevents pg_upgrade_support oid assignment when not in upgrade mode.
> It also modifies pg_upgrade to use this new mode rather than play with
> trying to stop autovacuum.
>
> This does fix a very rare bug that could happen if
> autovacuum_freeze_max_age were set to maximum by the user.
>
> I think this should be applied to PG 9.1.
One big problem with this patch is that it will not allow people to use
pg_upgrade when upgrading from 9.1 alpha to beta. What I could do is to
use the mode only on the "new" cluster for 9.1.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +