pg_ctl -w vs unix_socket_directory

This has a trivial workaround - just set PGHOST for pg_ctl:

[andrew@constanza inst.codfix.5705]$
PGHOST=/home/andrew/pgl/inst.codfix.5705 bin/pg_ctl -D data/ -l logfile
-w start
waiting for server to start.... done
server started
[andrew@constanza inst.codfix.5705]$

cheers

andrew

Radoslaw Zielinski wrote:

Andrew Dunstan <andrew@dunslane.net> [18-09-2007 23:42]:

This has a trivial workaround - just set PGHOST for pg_ctl:

[andrew@constanza inst.codfix.5705]$
PGHOST=/home/andrew/pgl/inst.codfix.5705 bin/pg_ctl -D data/ -l logfile -w
start

That would be fine for a particular installation, but isn't really
suitable for a startup script shipped with a linux distribution. Sure,
a /bin/sh-based postgresql.conf parser could do the trick... but I just
don't feel like writing one. :-)

--
Radosław Zieliński <radek@pld-linux.org>

Radoslaw Zielinski <radek42@gmail.com> writes:

"pg_ctl -w -D ... start" doesn't work when unix_socket_directory is set
to somewhere else than the compiled in default ("/tmp").

pg_ctl not working is going to be the very least of your worries;
pretty much nothing else will either.

If you want some other socket directory, I strongly recommend setting
the path to it at compile time so that it's properly wired into libpq.
AFAICS the only value in specifying unix_socket_directory at server
start is if you actually *want* a stealth server that won't be found
by clients without manual intervention.

regards, tom lane

Radoslaw Zielinski wrote:

Andrew Dunstan <andrew@dunslane.net> [18-09-2007 23:42]:

This has a trivial workaround - just set PGHOST for pg_ctl:

[andrew@constanza inst.codfix.5705]$
PGHOST=/home/andrew/pgl/inst.codfix.5705 bin/pg_ctl -D data/ -l logfile -w
start

That would be fine for a particular installation, but isn't really
suitable for a startup script shipped with a linux distribution. Sure,
a /bin/sh-based postgresql.conf parser could do the trick... but I just
don't feel like writing one. :-)

I think it's broken for a distro to ship with config files setting a
socket dir other than the one they compile in.

If you don't like /tmp compile in something else. The you don't need to
parse anything.

cheers

andrew

On 19/09/2007, Andrew Dunstan <andrew@dunslane.net> wrote:

Radoslaw Zielinski wrote:

[...]

That would be fine for a particular installation, but isn't really
suitable for a startup script shipped with a linux distribution. Sure,

[...]

I think it's broken for a distro to ship with config files setting a
socket dir other than the one they compile in.

The distro uses the default, of course. The issue is: the startup
script stops working if a sysadmin changes it manually, for whatever
reason.

On 19/09/2007, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Radoslaw Zielinski <radek42@gmail.com> writes:

"pg_ctl -w -D ... start" doesn't work when unix_socket_directory is set
to somewhere else than the compiled in default ("/tmp").

pg_ctl not working is going to be the very least of your worries;
pretty much nothing else will either.

If you want some other socket directory, I strongly recommend setting

[...]

I don't want any other socket directory. All I want is a way to
create a working startup script: able to start/stop the server
regardless of changes in postgresql.conf and report the success or
failure.

On Tue, 2007-09-18 at 19:13 -0400, Tom Lane wrote:

Radoslaw Zielinski <radek42@gmail.com> writes:

"pg_ctl -w -D ... start" doesn't work when unix_socket_directory is set
to somewhere else than the compiled in default ("/tmp").

pg_ctl not working is going to be the very least of your worries;
pretty much nothing else will either.

If you mean client applications won't work, that would be expected from
such a change to the server configuration.

If you want some other socket directory, I strongly recommend setting
the path to it at compile time so that it's properly wired into libpq.
AFAICS the only value in specifying unix_socket_directory at server
start is if you actually *want* a stealth server that won't be found
by clients without manual intervention.

Those arguments apply almost as well to the server port. The server port
is read from the postgresql.conf from pg_ctl, but not the socket
directory.

It's an annoyance: if you change the default socket directory, you're
probably going to break your init script (on FreeBSD you will, because
it uses "-w"). I don't think that's the expected result, and it's not
intuitive to find the cause of the problem.

I think the inconsistency between server port number and socket
directory is less than ideal. However, I also don't feel very strongly
about it. It's rare, and a there are plenty of workarounds.

Regards,
Jeff Davis