Josh Kupershmidt <schmi...@gmail.com> writes:
> You can run the test case stand-alone, though it's probably easier to
> see what's going on if you just copy-paste into your terminal: at the
> end you should wind up with your current directory "/tmp/foo/". You
> should see that the last command, "pg_ctl -D $DATADIR restart" failed
> to start the server back up, complaining:
> postgres cannot access the server configuration file
> "/tmp/foo/baz/postgresql.conf": No such file or directory
> even though $DATADIR is clearly set to "/tmp/foo/bar/baz/" (N.B.
> directory "bar" has gone missing in the above error message). A
> "pg_ctl -D $DATADIR start" should work at this point, though. This
> seems like some bug in normalizing the absolute path to
> postgresql.conf.
I think the reason it has a problem is that this is what's left in
postmaster.opts:
/home/tgl/pgsql/bin/postgres "-D" "baz"
(which is an accurate representation of the command line from startup)
and that -D switch gets fed to the postmaster as-is during restart.
By and large, I would not recommend using a relative pathname to start
the postmaster, unless you plan to start it from the same working
directory every time.
We could possibly avoid this by having pg_ctl try to absolute-ify the -D
setting during postmaster start, but I'm not convinced it's worth the
trouble, or even that it's appropriate for pg_ctl to editorialize on the
user's choice of absolute vs relative path.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
