Re: abstract Unix-domain sockets

On 2020-11-24 16:49, David G. Johnston wrote: On Tue, Nov 24, 2020 at 8:45 AM Peter Eisentraut > wrote: 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

Re: abstract Unix-domain sockets

On 2020-11-24 02:57, Michael Paquier wrote: On Fri, Nov 20, 2020 at 04:06:43PM +0100, Peter Eisentraut wrote: I think we are getting a bit sidetracked here with the message wording. The reason I looked at this was that "remove socket file and retry" is never an appropriate action with abstract

Re: abstract Unix-domain sockets

On Tue, Nov 24, 2020 at 8:45 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > 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

Re: abstract Unix-domain sockets

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

Re: abstract Unix-domain sockets

On Mon, Nov 23, 2020 at 9:00 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > 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? > This

Re: abstract Unix-domain sockets

On Fri, Nov 20, 2020 at 04:06:43PM +0100, Peter Eisentraut wrote: > I think we are getting a bit sidetracked here with the message wording. The > reason I looked at this was that "remove socket file and retry" is never an > appropriate action with abstract sockets. And on further analysis, it is

Re: abstract Unix-domain sockets

On Mon, Nov 23, 2020 at 6:50 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.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

Re: abstract Unix-domain sockets

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

Re: abstract Unix-domain sockets

On Friday, November 20, 2020, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-11-18 04:35, David G. Johnston wrote: > >> >> >> I agree that there isn't a useful hint for the abstract case as it >> shouldn't happen unless there is indeed another running instance with the >>

Re: abstract Unix-domain sockets

separate thread. -- Peter Eisentraut 2ndQuadrant, an EDB company https://www.2ndquadrant.com/ From a4967dd79e490390bc148d3bae92452ba4a34c9c Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Thu, 22 Oct 2020 08:47:52 +0200 Subject: [PATCH v3 1/2] Add support for abstract Unix-domain sockets Thi

Re: abstract Unix-domain sockets

On Tue, Nov 17, 2020 at 7:00 PM Michael Paquier wrote: > On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote: > > So the mention of the "port" doesn't really add any information here and > > just introduces new terminology that isn't really relevant. > > > > My idea is to change the

Re: abstract Unix-domain sockets

On Fri, Oct 9, 2020 at 3:28 PM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > During the discussion on Unix-domain sockets on Windows, someone pointed > out[0] abstract Unix-domain sockets. > This reminds me on a somewhat random note that SSPI mode authentication

Re: abstract Unix-domain sockets

On Tue, Nov 17, 2020 at 11:18:12PM +0100, Peter Eisentraut wrote: > So the mention of the "port" doesn't really add any information here and > just introduces new terminology that isn't really relevant. > > My idea is to change the message to: > > ERROR: could not bind Unix address

Re: abstract Unix-domain sockets

On 2020-11-12 08:12, Michael Paquier wrote: On Wed, Nov 11, 2020 at 01:39:17PM +0100, Peter Eisentraut wrote: Thinking about it further, I think the hint in the Unix-domain socket case is bogus. A socket in the file-system namespace never reports EADDRINUSE anyway, it just overwrites the file.

Re: abstract Unix-domain sockets

On Wed, Nov 11, 2020 at 01:39:17PM +0100, Peter Eisentraut wrote: > Thinking about it further, I think the hint in the Unix-domain socket case > is bogus. A socket in the file-system namespace never reports EADDRINUSE > anyway, it just overwrites the file. For sockets in the abstract namespace,

Re: abstract Unix-domain sockets

On 2020-11-10 07:24, Michael Paquier wrote: Can you sketch how you would structure this? I realize it's not very elegant, but I couldn't come up with a better way that didn't involve having to duplicate some of the error messages into multiple branches. I think that I would use a StringInfo

Re: abstract Unix-domain sockets

On Mon, Nov 09, 2020 at 09:04:24AM +0100, Peter Eisentraut wrote: > On 2020-11-09 07:08, Michael Paquier wrote: > The @ is the standard way of representing this in the user interface and the > configuration, so it seems sensible to me that way. Ok. > Can you sketch how you would structure this?

Re: abstract Unix-domain sockets

On 11/9/20 9:04 AM, Peter Eisentraut wrote: On 2020-11-09 07:08, Michael Paquier wrote: As abstract namespaces don't have permissions, anyone knowing the name of the path, which should be unique, can have an access to the server. Do you think that the documentation should warn the user about

Re: abstract Unix-domain sockets

On 2020-11-09 07:08, Michael Paquier wrote: As abstract namespaces don't have permissions, anyone knowing the name of the path, which should be unique, can have an access to the server. Do you think that the documentation should warn the user about that? This feature is about easing the

Re: abstract Unix-domain sockets

On Thu, Oct 22, 2020 at 09:03:49AM +0200, Peter Eisentraut wrote: > On 2020-10-09 09:28, Peter Eisentraut wrote: >> During the discussion on Unix-domain sockets on Windows, someone pointed >> out[0] abstract Unix-domain sockets. This is a variant of the normal >> Unix-doma

Re: abstract Unix-domain sockets

Updated patch set after some conflicts had emerged. On 2020-10-09 09:28, Peter Eisentraut wrote: During the discussion on Unix-domain sockets on Windows, someone pointed out[0] abstract Unix-domain sockets. This is a variant of the normal Unix-domain sockets that don't use the file system

abstract Unix-domain sockets

During the discussion on Unix-domain sockets on Windows, someone pointed out[0] abstract Unix-domain sockets. This is a variant of the normal Unix-domain sockets that don't use the file system but a separate "abstract" namespace. At the user interface, such sockets are represente