Lists: | pgsql-bugs |
---|
From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | 'pg_ctl restart' confused about pathname to postgresql.conf |
Date: | 2011-10-21 21:51:28 |
Message-ID: | CAK3UJRGABxWSOCXnAsSYw5BfR4D9ageXF+6GtsRVm-LtfWfW=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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 | Content-Type | Size |
---|---|---|
pg_ctl_weirdness.sh | application/x-sh | 845 bytes |
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 |
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: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: 'pg_ctl restart' confused about pathname to postgresql.conf |
Date: | 2011-10-24 00:49:25 |
Message-ID: | CAK3UJREBLRhCjDQ_UoErQ9ifG3M15jQWsQPx-S9O5=vhz-+7BA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
On Sat, Oct 22, 2011 at 12:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: 'pg_ctl restart' confused about pathname to postgresql.conf |
Date: | 2012-08-16 22:16:46 |
Message-ID: | 20120816221646.GA30286@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-bugs |
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(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment | Content-Type | Size |
---|---|---|
pg_ctl.diff | text/x-diff | 823 bytes |