On 2020-11-20 18:23, David G. Johnston wrote: > If there is dead code there is an underlying problem to > address/discover, not just removing the dead code. In this case are we > saying that a new server won’t ever fail to start because the socket > file exists but instead will just clobber the file with its own?
Yes. (In practice, there will be an error with respect to the lock file before you even get to that question, but that is different code elsewhere.)
> Because given that error, and a server process that failed to clean up > after itself, the correction to take would indeed seem to be to manually > remove the file as the hint says. IOW, fix the code, not the message?
I don't understand that.
So presently there is no functioning code to prevent two PostgreSQL instances from using the same socket so long as they do not also use the same data directory? We only handle the case of an unclean crash - where the pid and socket are both left behind - having the system tell the user to remove the pid lock file but then auto-replacing the socket (I was conflating the behavior with the pid lock file and the socket file).
I would expect that we handle port misconfiguration also, by not auto-replacing the socket and instead have the existing error message (with modified hint) remain behind. This provides behavior consistent with TCP port binding. Or is it the case that we always attempt to bind the TCP/IP port, regardless of the presence of a socket file, in which case the failure for port binding does cover the socket situation as well? If this is the case, pointing that out in [1] and a code comment, while removing that particular error as "dead code", would work.
