Re: abstract Unix-domain sockets

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: abstract Unix-domain sockets
Date: 2020-11-24 15:45:11
Message-ID: 43060bbb-da4b-f810-f87e-921f0f122c39@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-11-23 17:00, David G. Johnston wrote:
> 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.

We're subject to whatever the kernel behavior is. If the kernel doesn't
report address conflicts for Unix-domain sockets, then we can't do
anything about that. Having an error message ready in case the kernel
does report such an error is not useful if it never does.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-11-24 15:47:02 Re: [HACKERS] Custom compression methods
Previous Message Justin Pryzby 2020-11-24 15:31:23 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly