abstract Unix-domain sockets - Mailing list pgsql-hackers

From Peter Eisentraut
Subject abstract Unix-domain sockets
Date
Msg-id 6dee8574-b0ad-fc49-9c8c-2edc796f0033@2ndquadrant.com
Whole thread Raw
Responses Re: abstract Unix-domain sockets
Re: abstract Unix-domain sockets
List pgsql-hackers
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 
represented by names starting with "@".  I took a look at this and it 
wasn't hard to get working, so here is a patch.  It's supposed to be 
supported on Linux and Windows right now, but I haven't tested on Windows.

I figure, there are so many different deployment options nowadays, this 
could be useful somewhere.  It relieves you from dealing with the file 
system, you don't have to set up /tmp or something under /var/run, you 
don't need to make sure file system permissions are right.  Also, there 
is no need for a lock file or file cleanup.  (Unlike file-system 
namespace sockets, abstract namespace sockets give an EADDRINUSE when 
trying to bind to a name already in use.)  Conversely, of course, you 
don't get to use file-system permissions to manage access to the socket, 
but that isn't essential functionality, so it's a trade-off users can 
make on their own.

And then some extra patches for surrounding cleanup.  During testing I 
noticed that the bind() failure hint "Is another postmaster already 
running ..." was shown in inappropriate situations, so I changed that to 
only show for EADDRINUSE errors.  (Maybe other error codes could be 
appropriate, but I couldn't find any more.)

And then looking for other uses of EADDRINUSE I found some dead 
Windows-related code that can be cleaned up.


[0]: 
https://www.postgresql.org/message-id/20191218142419.fvv4ikm4wq4gnkco@isc.upenn.edu

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Transactions involving multiple postgres foreign servers, take 2
Next
From: Thomas Munro
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)