Re: abstract Unix-domain sockets
От | Peter Eisentraut |
---|---|
Тема | Re: abstract Unix-domain sockets |
Дата | |
Msg-id | 43060bbb-da4b-f810-f87e-921f0f122c39@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: abstract Unix-domain sockets ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: abstract Unix-domain sockets
|
Список | 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/
В списке pgsql-hackers по дате отправления: