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

Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of lun oct 03 16:09:08 -0300 2011:
>
> > Alvaro Herrera wrote:
>
> > > My guess is that we could fix the simple case (the one that doesn't
> > > involve a "-o datadir" option) with the parse-and-report option that has
> > > been mentioned, and dictate that the other one doesn't work. That's
> > > much less likely to cause a problem in practice.
> >
> > 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. :-(
>
> If we don't do anything, then it's never going to work. If we do it
> today, we can have it working in the next release (9.2, right?).

No, old and new have to support this in both the postgres and pg_ctl
binaries, which is why I said 2+ years, e.g. going from 9.1 to 9.3 is
not going to work, unless we backpatch, and then we have to make sure
users are on later minor versions.

> "It doesn't work now but will work in the next release; and here's a
> workaround that can get you out for now" is a useful if painful answer;
> "it's never going to work" is a lot worse.
>
> We've been in that sort of situation before, and the answer has always
> been to fix the issue for future users. Assuming the world doesn't end
> next year (a safe bet if you ask me), those are going to be more common
> that current users, so it's worth the hassle.
>
> > Yes, auto-creation of symlinks would be useful, but at that point pg_ctl
> > and pg_upgrade would have to use the real data directory, so I again
> > wonder what the config-only directory is getting us.
>
> Not mixing config stuff (in /etc per FHS) with server data (/var/lib,
> again per FHS). It's Debian policy anyway. I don't judge whether this
> is sane or not. See
> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Yes, but why not do this via symlinks? The problem is pg_ctl has to
read server _state_ which cannot be put in a configuration directory,
and we don't even require the real data directory to be recorded in the
config file.

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

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