Re: Unix socket dir, an idea

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Danylo Hlynskyi <abcz2(dot)uprola(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Unix socket dir, an idea
Date: 2019-03-30 00:40:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Danylo Hlynskyi <abcz2(dot)uprola(at)gmail(dot)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

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-03-30 01:08:22 Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru
Previous Message Tom Lane 2019-03-30 00:17:32 Re: speeding up planning with partitions