Re: -Wformat-zero-length - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: -Wformat-zero-length
Date
Msg-id 20120808230441.GB24079@momjian.us
Whole thread Raw
In response to Re: -Wformat-zero-length  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: -Wformat-zero-length
List pgsql-hackers
On Wed, Aug  8, 2012 at 06:42:27PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@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.1340655654@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.

We now use a temporary port number, 50432.

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

Agreed.  Even with these changes, I still see a lot of complexity.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: -Wformat-zero-length
Next
From: Simon Riggs
Date:
Subject: Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover