On Sat, Oct 22, 2011 at 12:13 PM, Tom Lane <t...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
