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

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:
> > On Tue, Aug 7, 2012 at 10:59 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > > Yes, the list of rough edges is the 14-steps you have to perform to run
> > > pg_upgrade, as documented in the pg_upgrade manual page:
> > >
> > >         http://www.postgresql.org/docs/9.2/static/pgupgrade.html
> > >
> > > The unknown is how to reduce the number of steps in a way the community
> > > would find acceptable.
> >
> > I think this is one good idea:
> >
> > http://archives.postgresql.org/message-id/29806.1340655654@sss.pgh.pa.us
> >
> > The number of steps is an issue, but the likelihood of the actual
> > pg_upgrade run failing or doing the wrong thing is also something we
> > need to work on.
>
> If we currently require 14 steps to use pg_upgrade, how would that
> reduce this number?  What failures does it fix?

I think those 14 is a bit of a made-up number.  Several of those steps
are about building pg_upgrade, not actually using it.  And there are
some that are optional anyway.

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.

Another thing worth considering is to have pg_upgrade init, stop and
start clusters as necessary instead of requesting the user to do it.
I think this is two less steps.


I wonder if things would be facilitated by having a config file for
pg_upgrade to specify binary and PGDATA paths instead of having awkward
command line switches.  That way you could request the user to create
such a file, then

# this runs the checks, gathers necessary .so files, stops old cluster,
# runs initdb for new cluster
pg_upgrade --config=/somewhere/pg_upgrade.conf --init-new

# now plead the user to install the .so files into the new cluster

# do the actual upgrade
pg_upgrade --config=/somewhere/pg_upgrade.conf --actually-upgrade


You could even have a mode on which pg_upgrade asks for the necessary
information to create the config file.  For example

pg_upgrade --create-config=/somewhere/pg_upgrade.conf
Path to new binaries:  /usr/local/pg92
Path to old binaries:  /usr/local/pg84
Path to old data directory:  /srv/pgsql-84/data
Path to new data directory:  /srv/pgsql-92/data
Use link mode (y/N):  n
... using copy mode.
[now run the checks and complain about missing binaries, etc]

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services