Re: abstract Unix-domain sockets

On Tue, Nov 17, 2020 at 7:00 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote:
> > So the mention of the "port" doesn't really add any information here and
> > just introduces new terminology that isn't really relevant.
> >
> > My idea is to change the message to:
> >
> > ERROR: could not bind Unix address "/tmp/.s.PGSQL.5432": Address
> already in
> > use
> > HINT: Is another postmaster already running at this address?
>
> Are you saying that you would remove the hint telling to remove the
> socket file even for the case of non-abstract files? For abstract
> paths, this makes sense. For both, removing the "port" part is indeed
> a good idea as long as you keep around the full socket file name.
>
>
(resending to the list)

Given that "port" is a postgresql.conf setting its use here (and elsewhere)
should be taken to mean the value of that specific variable. To that end,
I find the current description of port to be lacking - it should mention
its usage as a qualifier when dealing with unix socket files (in addition
to the existing wording under unix_socket_directories).

If we are going to debate semantics here "bind unix address" doesn't seem
correct. could not create Unix socket file /tmp/.s.PGSQL.5432, it already
exists.

The hint would be better written: Is another postmaster running with
unix_socket_directories = /tmp and port = 5432? If not, remove the unix
socket file /tmp/.s.PGSQL.5432 and retry.

I don't see much benefit in trying to share logic/wording between the
various messages and hints for the different ways the server can establish
communication points.

I agree that there isn't a useful hint for the abstract case as it
shouldn't happen unless there is indeed another running instance with the
same configuration. Though a hint similar to the above, but without the
"remove and retry" bit, probably wouldn't hurt.

David J.