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