Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On ons, 2011-09-28 at 11:53 -0300, Alvaro Herrera wrote:
> > > Excerpts from Peter Eisentraut's message of mi? sep 28 04:49:43 -0300 2011:
> > > > On tis, 2011-09-27 at 16:13 -0700, Steve Crawford wrote:
> > > > > It would perhaps be useful to add optional --old-confdir and
> > > > > --new-confdir parameters to pg_upgrade. If these parameters are absent
> > > > > then pg_upgrade would work as it does now and assume that the config
> > > > > files are in the datadir.
> > > >
> > > > It should work the same way the postmaster itself works: If the given
> > > > directory is not a data directory, look for the postgresql.conf file and
> > > > look there for the location of the data directory.
> > >
> > > So we need a postmaster switch:
> > >
> > > postmaster --parse-config-and-report=data_directory
> >
> > Perhaps. That might have some use for pg_ctl as well.
>
> FYI, unless this is backpatched, which I doubt, it is only going to be
> available for the _new_ cluster.
>
> You are right that while pg_upgrade doesn't care about the location of
> postgresql.conf and pg_hba.conf, we have to point to those to start the
> server, and pg_upgrade does need to access some data files, so it also
> needs to know about the data location.
>
> I am unclear how to proceed with this, particularly with the backpatch
> requirement.
Thinking some more, I don't need to know the data directory while the
server is down --- I already am starting it. pg_upgrade starts both old
and new servers during its check phase, and it could look up the
data_directory GUC variable and use that value when accessing files.
That would work for old and new servers. However, I assume that is
something we would not backpatch to 9.1.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
