Re: Unix socket dir, an idea - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Unix socket dir, an idea
Date
Msg-id 25758.1553906401@sss.pgh.pa.us
Whole thread Raw
In response to Unix socket dir, an idea  (Danylo Hlynskyi <abcz2.uprola@gmail.com>)
Responses Re: Unix socket dir, an idea
List pgsql-hackers
Danylo Hlynskyi <abcz2.uprola@gmail.com> writes:
> The problem (as I see it) is that everybody would like to move `/tmp`
> socket dir to `/var/run`, or even `/var/run/postgresql` (or even
> `/run/postgresql`), but compatibility with old clients (which connect to
> /tmp by default) is a concern.

*Some* people would like to move the default socket location.  Others
of us see that as a recipe for chaos.  If it's really easy to change
that, we're going to have a Babel of servers and clients that can't
talk to each other.

I would also like to point out the extreme Unix-centricity (and
even particular-distribution-centricity) of the alternative locations
you mention, as well as the fact that all those locations are unfriendly
to running an unprivileged postmaster (i.e. one that hasn't been
explicitly blessed by whoever has root on the box).

> 1. Add a Makefile parameter CONFIG_PGSOCKET_DIR to explicitly switch to new
> unix socket directory, and let distributions decide if they want this, and
> if they want, they should handle socket dir change on their own.

We already have DEFAULT_PGSOCKET_DIR in pg_config_manual.h, and distros
that want to change it typically carry a patch to adjust that header.
I'm not sure we really want to make it any easier than that.

> 2. The new socket directory shouldn't be hardcoded to single directory,
> instead it should be detected dynamically.

This idea is just nuts.  It makes each of the problems I mentioned above
about ten times worse.

> For client:
> - if host explicitly set, use it
> - if not, check if /run/user/$(id -u) exists and socket file exists there.
> If yes, use it as socket

Uh, how is a client supposed to know what UID the postmaster is running
under?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: speeding up planning with partitions
Next
From: Michael Paquier
Date:
Subject: Re: pgsql: Improve autovacuum logging for aggressive andanti-wraparound ru