Re: Ability to listen on two unix sockets - Mailing list pgsql-hackers

From Honza Horak
Subject Re: Ability to listen on two unix sockets
Date
Msg-id 4FD8924D.3010801@redhat.com
Whole thread Raw
In response to Re: Ability to listen on two unix sockets  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Ability to listen on two unix sockets  (Florian Pflug <fgp@phlo.org>)
Re: Ability to listen on two unix sockets  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 06/10/2012 12:37 AM, Peter Eisentraut wrote:
> On sön, 2012-06-10 at 00:25 +0200, Andres Freund wrote:
>>>>> We already have the ability to configure the Unix socket
>> directory in
>>>>> postgresql.conf.  All you need to do is turn that into a list.
>>>> That doesn't help libpq using clients.
>>> There is no mandate here to do anything about that.
>> Well, Martin Pitt/the debian package is patching exactly that. Youre
>> saying
>> that everything that needs to be done to make that easier is to make
>> unix_socket_dir a list. So there seems to be some disparity there ;)
>>
> The Debian package doesn't need any change or assistance, really.  You
> can change the default location of the socket by patching
> pg_config_manual.h, and that's a one-liner.  The only thing that would
> make that slightly easier or better is making it a configure option, but
> that was intentionally decided against in the old days (not by me).

Since systemd with it's PrivateTmp feature is going to be used in more
and more distros, there will probably be a bigger need to solve
in-accessible default unix socket directory /tmp in the future.

Thus, I'd like to ask if anybody is aware of any issue connected with
simply patching pg_config_manual.h, same as Debian does it already? For
example, is there any piece of software, that simply rely on /tmp
location of the socket and doesn't use libpg for the communication?

Regards,
Honza


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: [PATCH 13/16] Introduction of pair of logical walreceiver/sender
Next
From: Merlin Moncure
Date:
Subject: Re: hint bit i/o reduction