Re: -Wformat-zero-length

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: -Wformat-zero-length
Date: 2012-08-08 21:29:49
Message-ID: 1344460749-sup-4192@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2012-08-08 21:58:33 Re: -Wformat-zero-length
Previous Message Bruce Momjian 2012-08-08 21:15:38 Re: -Wformat-zero-length