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

From Marko Kreen
Subject Re: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files
Date
Msg-id 20001127191651.A23317@l-t.ee
Whole thread Raw
In response to Re: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Nov 27, 2000 at 11:05:40AM -0500, Tom Lane wrote:
> 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.

I do not see this much of a problem tho'.

[ I use the words XCONFIG and XNAME because I have no good idea
what they should be called. ]

server startup precedence:

1) postmaster --xconfig ./foo.cfg
2) PG_XCONFIG=./foo.cfg
3) /etc/postgresql/pg_xconfig (compile time spec)

there is also a thing 'xname' which is the section of config
file to use:

1) --xname foodb
2) PG_XNAME=foodb
3) default_xname specified in config.

so, client (libpq (psql)) startup:

1) psql --xconfig ./xxx
2) PG_XCONFIG=./xxx
3) ~/.pg_xconfig
4) /etc/postgresql/pg_xconfig

and xname as in server.


It may be better if server config is in separate file because we
may want to give more options to server (ipc keys, data dirs,
etc).  But I guess its sipler when they read the same file and
client simply ignores server directives.  And server ignores
remote servers.

Also it should be possible to put all directives into commend
line too, for both client and server.

> 
> 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.

postmaster --xconfig ./test.cfg --xname testdb &
psql --xconfig ./test.cfg --xname testdb

> 
> 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.

So what you think of the above idea?

-- 
marko



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [NOVICE] Re: re : PHP and persistent connections
Next
From: Mario Weilguni
Date:
Subject: Question about Oracle compatibility