Re: pg_ctl -w vs unix_socket_directory

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Radoslaw Zielinski <radek42(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_ctl -w vs unix_socket_directory
Date: 2007-09-19 19:04:58
Message-ID: 1190228698.5943.57.camel@dogma.ljc.laika.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2007-09-18 at 19:13 -0400, Tom Lane wrote:
> Radoslaw Zielinski <radek42(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2007-09-19 19:28:29 Re: Debugger
Previous Message Gregory Stark 2007-09-19 19:02:09 Re: curious regression failures