| 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: | Whole Thread | Raw Message | 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 |