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