On Tue, Nov 17, 2020 at 7:00 PM Michael Paquier <michael@paquier.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.
