Re: abstract Unix-domain sockets

On Mon, Nov 23, 2020 at 6:50 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> 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.

David J.

[1]
https://www.postgresql.org/docs/13/server-start.html#SERVER-START-FAILURES