Robert Haas wrote: > On Mon, Oct 3, 2011 at 3:09 PM, Bruce Momjian <br...@momjian.us> wrote: > > Well, we are unlikely to backpatch that parse-and-report option so it > > would be +2 years before it could be expected to work for even > > single-major-version upgrades. ?That just seems unworkable. ?Yeah. :-( > > I'd like to see the patch first, but I am not convinced that we > couldn't back-patch this. I am not a big fan of back-patching things > that are not bug fixes, but I think you can make a fairly reasonable > argument that this is a bug in pg_ctl, and therefore in pg_upgrade, > and that we should therefore fix it. Frankly, I think the > parse-and-report option is the least of our troubles. Implementing > that much without breaking anything seems like it should be quite > straightforward. If that's all we need to get ourselves out of this > mess, then let's just go do it (carefully).
We can't work on a patch until we have the defined behavior we want and it should be understandable. > The trickier part is that you then have to make sure that - in the > course of fixing the cases where pg_ctl behaves properly today - you > don't make any backward-incompatible behavior changes. Just for > example, we can't make a unilateral decision now that - in > split-config scenarios - pg_ctl should always be invoked with a -D > argument that points to the postgresql.conf directory rather than the > data directory, because per your email upthread there are cases where > that doesn't work today, and therefore people are probably pointing at > the data directory. But we probably *could* get away with making > cases work that are currently broken - e.g. allow pg_ctl stop -D $FOO > to work if $FOO is *either* the config dir or the real data dir. Now, > is that too much to back-patch? Without having looked at the code, > I'm not sure, but it might turn out it's not that bad. We've > certainly back-patched scarier stuff before when it's been necessary > to fix bugs - see, for example, commit > ceaf5052c6a7bee794211f5d4c503639bdf3dff0. pg_ctl would have to do some detective work to see if PG_VERSION existed in that directory and adjust its behavior --- the pg_upgrade patch I posted does this kind of detection. The goal is the change would happen only for people using config-only directories, and when a config-only directory is specified. > Furthermore, if we look at this and ultimately conclude that it's too > invasive to back-patch, all is not lost. We have a recommended layout > for our tree, and the Ubuntu and Gentoo folks have decided not to use > it (which is perfectly fine), and they have installed various > workarounds for problems like "pg_ctl doesn't work well with that > directory layout". This will be another scenario that they will need > to work around, and I'm guessing that they are more than capable of > doing that (if they aren't, perhaps they shouldn't have insisted on a > different layout in the first place... but I don't think that's the > case). We can also document the workarounds for other users who have Yes, they are using symlinks now to work around the pg_upgrade/pg_ctl problem. > this problem, and we can fix it for real in 9.2. Sure, that will mean > it's 2+ years before people really start being able to take advantage > of the new features, but I don't think that makes it not worth doing. > Rome wasn't built in a day, and this didn't get broken in a day. I'm > not abandoning all hope of a short-term fix, but even if we do give up > on that, I don't think that a long-term fix plus some documentation of > what to do meanwhile is a crazy approach to the problem. I can't figure out what a non-crazy solution looks like. -- 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
