Re: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files
Date
Msg-id 10959.975341140@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files  (Marko Kreen <marko@l-t.ee>)
Responses Re: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files
List pgsql-hackers
Marko Kreen <marko@l-t.ee> writes:
>> Well, we've talked before about moving the socket files to someplace
>> safer than /tmp.  The problem is to find another place that's not
>> platform-dependent --- else you've got a major configuration headache.

> Could this be described in e.g. /etc/postgresql/pg_client.conf?

The major objection to that is that if we rely on such a config file,
then you *cannot* install postgres without root permission (to make
the config file).  Currently it's possible to fire up a test postmaster
without any special privileges whatever, and that's a nice feature.

A related objection is that such a file will itself become a source of
contention among multiple postmasters.  Suppose I'm setting up a test
installation of a new version, while still running the prior release
as my main database.  OK, I fire up the test postmaster on a different
port, and now I want to launch some of my usual clients for testing.
Oops, they connect to the old postmaster because that's what it says
to do in /etc/postgresql/pg_client.conf.  I can't get them to connect
to the new postmaster unless I change /etc/postgresql/pg_client.conf,
which I *don't* want to do at this stage --- it'll break non-test
instances of these same clients.

I see some value in the pg_client.conf idea as a *per user* address
book, to shortcut full specification of all the databases that user
might want to connect to.  As a system-wide configuration file, I think
it's a terrible idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: Re: [NOVICE] Re: re : PHP and persistent connections
Next
From: Bruce Momjian
Date:
Subject: Re: AW: Final proposal for resolving C-vs-newC issue