Thread: 'pg_ctl restart' confused about pathname to postgresql.conf
I've noticed that I occasionally see errors from "pg_ctl restart" claiming: postgres cannot access the server configuration file ... No such file or directory depending on what directory I execute "pg_ctl restart" from, and where the postmaster was originally started from. I boiled this problem down to the attached test case. I've seen this problem on 9.1.1 and git head. The testcase was tried on OS X and Debian, with Postgres installed locally like this: ./configure --prefix=/home/postgres/runtime/ --with-python --enable-debug 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. Josh
Attachment
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. +