Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Excerpts from Bruce Momjian's message of mié ago 08 17:15:38 -0400 2012: >> On Wed, Aug 8, 2012 at 04:23:04PM -0400, Robert Haas wrote: >>> I think this is one good idea: >>> http://archives.postgresql.org/message-id/29806.1340655...@sss.pgh.pa.us
>> If we currently require 14 steps to use pg_upgrade, how would that >> reduce this number? What failures does it fix? > The suggestion by Tom reduces the list by two steps because it doesn't > need to adjust pg_hba.conf or put it back in the original way > afterwards. Even more to the point, it flat-out eliminates failure modes associated with somebody connecting to either the old or the new cluster while pg_upgrade is working. Schemes that involve temporarily hacking pg_hba.conf can't provide any iron-clad guarantee, because if pg_upgrade can connect to a postmaster, so can somebody else. The point I think Robert was trying to make is that we need to cut down not only the complexity of running pg_upgrade, but the number of failure modes. At least that's how I'd define improvement here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers