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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers