Re: abstract Unix-domain sockets - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: abstract Unix-domain sockets
Date
Msg-id 3f24e287-846f-b4c6-f9a4-6a776a72419e@2ndquadrant.com
Whole thread Raw
In response to Re: abstract Unix-domain sockets  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: abstract Unix-domain sockets
Re: abstract Unix-domain sockets
List pgsql-hackers
On 2020-11-18 04:35, David G. Johnston wrote:
> 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.

I think we are getting a bit sidetracked here with the message wording. 
The reason I looked at this was that "remove socket file and retry" is 
never an appropriate action with abstract sockets.  And on further 
analysis, it is never an appropriate action with any Unix-domain socket 
(because with file system namespace sockets, you never get an 
EADDRINUSE, so it's dead code).  So my proposal here is to just delete 
that line from the hint and leave the rest the same.  There could be 
value in further refining and rephrasing this, but it ought to be a 
separate thread.

-- 
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/

Attachment

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: parsing pg_ident.conf
Next
From: Peter Eisentraut
Date:
Subject: Re: Removal of currtid()/currtid2() and some table AM cleanup