Re: abstract Unix-domain sockets
От | Peter Eisentraut |
---|---|
Тема | Re: abstract Unix-domain sockets |
Дата | |
Msg-id | 4ea6f358-2543-2536-fff7-8351ebb7be31@2ndquadrant.com обсуждение исходный текст |
Ответ на | abstract Unix-domain sockets (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: abstract Unix-domain sockets
|
Список | pgsql-hackers |
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 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. This last piece has been committed. > > > [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
Вложения
В списке pgsql-hackers по дате отправления: