Re: Bug with pg_ctl -w/wait and config-only directories

Robert Haas wrote:
> On Mon, Oct 3, 2011 at 3:09 PM, Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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