Bruce Momjian wrote: > Bruce Momjian wrote: > > Robert Haas wrote: > > > On Thu, Mar 31, 2011 at 12:11 PM, Bruce Momjian <br...@momjian.us> wrote: > > > > Robert Haas wrote: > > > >> On Thu, Mar 31, 2011 at 11:32 AM, Heikki Linnakangas > > > >> <heikki.linnakan...@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 <br...@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