Re: pg_upgrade - add config directory setting

Mr. Aaron W. Swenson wrote:
-- Start of PGP signed section.
> On Thu, Sep 29, 2011 at 10:44:29AM -0300, Alvaro Herrera wrote:
> >
> > Excerpts from Bruce Momjian's message of jue sep 29 09:56:09 -0300 2011:
> > >
> > > 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.
> >
> > Why not? We've supported separate data/config dirs for a long time now,
> > so it seems to me that pg_upgrade not coping with them is a bug. If
> > pg_upgrade starts postmaster, it seems simple to grab the data_directory
> > setting, is it not?
>
> I was going to say. I'd view this as bringing the behavior of pg_upgrade
> to a consistent state with postgres. I vote for it being backpatched to
> 9.0 even. For whatever my vote is worth.

Well, I would call it more of a limitation of pg_upgrade, rather than a
bug --- perhaps documenting the limitation in the back branches is
sufficient. I think the only big argument for backpatching the feature
is that 9.1 is the first release that packagers are going to use
pg_upgrade, and fixing it now makes sense because it avoids packagers
from implementing a workaround on every platform that will go away with
9.2.

So, there are four options:

1 document the limitation and require users to use symlinks
2 add a --old/new-configdir parameter to pg_upgrade
3 have pg_upgrade find the real data dir by starting the server
4 add a flag to some tool to return the real data dir, and backpatch
that

#4 has the problem of backpatching. I looked at #3 and the first thing
pg_upgrade does is to read PG_VERSION, and the second thing is to call
pg_controldata, both of which need the real data dir, so it is going to
require some major code ordering adjustments to do #3.

One interesting trick would be to start the old and new servers to pull
the data dir at the start only if we don't see PG_VERSION in the
specified data directory --- that would limit the overhead of starting
the servers, and limit the risk for backpatching.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +