[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Problem with pg_upgrade?
From:       Bruce Momjian <bruce () momjian ! us>
Date:       2011-03-31 20:18:10
Message-ID: 201103312018.p2VKIA823977 () momjian ! us
[Download RAW message or body]

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. :-)

Someone emailed me mentioning we might want to use this flag to cause
the server to use only local connections or lock it down in some other
way in the future.

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

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]