On Mon, Oct 3, 2011 at 21:55, Bruce Momjian <bruce@momjian.us> wrote:
> 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.
Well, how does the server get from the config file to where the state
file is? Can we do it the same way, or even expose it to the tools
using a commandline parameter or something?
Or looking just from the pg_upgrade perspective, can we get enough
info out of a running backend before sending signals, or do we need it
on startup as well?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/