From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: 'pg_ctl restart' confused about pathname to postgresql.conf |
Date: | 2011-10-22 16:13:45 |
Message-ID: | 9475.1319300025@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Josh Kupershmidt <schmiddy(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-10-23 02:16:58 | Re: [v9.2] make_greater_string() does not return a string in some cases |
Previous Message | Tom Lane | 2011-10-22 15:49:34 | Re: BUG #6264: Superuser does not have inherent Replication permission |