'pg_ctl restart' confused about pathname to postgresql.conf

Josh Kupershmidt <schmiddy@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

On Sat, Oct 22, 2011 at 12:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.

I see.

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.

Well, now I know. But that really seems like an annoying and arbitrary
restriction, not to mention not being documented anywhere AFAICT.

(I came upon this problem because I often set up servers with
binaries, libraries, and $PGDATA all tucked away under
/home/postgres/, and it seemed natural to use a relative pathname as
my data directory argument to pg_ctl since my working directory will
usually be /home/postgres/ when I'm poking at the server.)

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.

I don't want to bikeshed on the mechanics of how exactly this should
work, but it doesn't seem like it should be so hard to get this to
DWIM. In the example I posted, the last step which fails is basically:

pg_ctl -D /tmp/foo/bar/baz/ restart

and it just seems totally broken for that to not work: pg_ctl knows
exactly which data directory the user means when invoked here. Plus,
these steps would work fine instead at that point:

pg_ctl -D /tmp/foo/bar/baz/ stop
pg_ctl -D /tmp/foo/bar/baz/ start

and I was under the impression (supported by the pg_ctl doc page,
which claims "restart mode effectively executes a stop followed by a
start") that these sequences should be equivalent.

Josh

I have applied the attached doc patch to document the problem with
relative paths and pg_ctl restart.

---------------------------------------------------------------------------

On Sun, Oct 23, 2011 at 08:49:25PM -0400, Josh Kupershmidt wrote:

On Sat, Oct 22, 2011 at 12:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.

I see.

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.

Well, now I know. But that really seems like an annoying and arbitrary
restriction, not to mention not being documented anywhere AFAICT.

(I came upon this problem because I often set up servers with
binaries, libraries, and $PGDATA all tucked away under
/home/postgres/, and it seemed natural to use a relative pathname as
my data directory argument to pg_ctl since my working directory will
usually be /home/postgres/ when I'm poking at the server.)

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.

I don't want to bikeshed on the mechanics of how exactly this should
work, but it doesn't seem like it should be so hard to get this to
DWIM. In the example I posted, the last step which fails is basically:

pg_ctl -D /tmp/foo/bar/baz/ restart

and it just seems totally broken for that to not work: pg_ctl knows
exactly which data directory the user means when invoked here. Plus,
these steps would work fine instead at that point:

pg_ctl -D /tmp/foo/bar/baz/ stop
pg_ctl -D /tmp/foo/bar/baz/ start

and I was under the impression (supported by the pg_ctl doc page,
which claims "restart mode effectively executes a stop followed by a
start") that these sequences should be equivalent.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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