Florent Guillaume:
/tmp is for *temporary* files. Such a lock is not a temporary file,
it should go somewhere in /var, why not in /var/lib/pgsql/data ?
/var/run ?
--
Alessio F. Bragadini[EMAIL PROTECTED]
Trond Eivind Glomsrd wrote:
Tom Lane [EMAIL PROTECTED] writes:
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to overcome if we want to move the
socket files.
Lamar Owen [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd wrote:
Tom Lane [EMAIL PROTECTED] writes:
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to
Trond Eivind Glomsrd wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd wrote:
Not to sound scheptical, but since when did postgresql care about
backwards compatiblity? Upgrading is already demanding a lot of
Upgrading is only one facet of backwards compatibility.
I
Lamar Owen writes:
What about the X sockets, then?
Sockets are not the problem, regular files are. (At least for tmpwatch.)
But, let me ask this: is it a good thing for PostgreSQL clients to have
hard-coded socket locations? (Good thing or not, it exists already, and
I know it does)
Peter Eisentraut wrote:
Lamar Owen writes:
But, let me ask this: is it a good thing for PostgreSQL clients to have
hard-coded socket locations? (Good thing or not, it exists already, and
I know it does)
Perhaps there could be some sort of /etc/postgresql.conf file that is read
by
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
Ideally, the locks should be in /var/lock/pgsql and the socket
somewhere else - like /var/lib/pgsql (our mysql packages do this, and
both of them are specified in /etc/my.cnf).
That is not "ideal", in fact it would break one
Lamar Owen [EMAIL PROTECTED] writes:
I have another question of Peter, Tom, Bruce, or anyone -- is the
hard-coded socket location in libpq? If so, wouldn't a dynamically
loaded libpq.so bring this location in for _any_ precompiled, not
statically-linked, client? Or am I missing something
Peter Eisentraut [EMAIL PROTECTED] writes:
Perhaps there could be some sort of /etc/postgresql.conf file that is read
by both client and server that can control these sort of aspects.
Maybe ... but it seems to me that still leaves us with the issue of
a single pathname that must be known
Tom Lane [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
Ideally, the locks should be in /var/lock/pgsql and the socket
somewhere else - like /var/lib/pgsql (our mysql packages do this, and
both of them are specified in /etc/my.cnf).
(note
Tom Lane wrote:
So, yes, if an old client has a dynamically linked libpq.so then
replacing the .so would bring that client into sync with a nonstandard
server.
Of course, with the server and client on the same machine, the server
and the client dynamic libs are very likely to follow the same
Lamar Owen [EMAIL PROTECTED] writes:
How about an environment variable? PGSOCKLOC? Use the hard-coded
default if the envvar not set? This way multiple postmasters running on
multiple sockets can be smoothly supported.
It's spelled PGHOST as of 7.1 ... but the discussion here is about what
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
Explictly, yes. However, FHS says /tmp is for temporary files. Also,
it says programs shouldn't count on data to be stored there between
invocations. 10+ days isn't temporary...
We aren't counting on data to be stored in
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
How about an environment variable? PGSOCKLOC? Use the hard-coded
default if the envvar not set? This way multiple postmasters running on
multiple sockets can be smoothly supported.
It's spelled PGHOST as of 7.1 ... but the
Oliver Elphick wrote:
No, UNIX sockets are specifically mentioned as belonging under /var/run.
In section 5.10 "/var/run : Run-time variable data", it says: "Programs
that maintain transient UNIX-domain sockets should place them in this
directory."
So what ever the outcome for the wider
Lamar Owen wrote:
Tom Lane wrote:
It's spelled PGHOST as of 7.1 ... but the discussion here is about what
the default behavior of an installation will be, not what you can
override it to do.
I'm talking about Unix domain socket location, not TCP/IP hostname,
which PGHOST is, right?
Tom Lane [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
Explictly, yes. However, FHS says /tmp is for temporary files. Also,
it says programs shouldn't count on data to be stored there between
invocations. 10+ days isn't temporary...
We
Lamar Owen [EMAIL PROTECTED] writes:
Oliver Elphick wrote:
No, UNIX sockets are specifically mentioned as belonging under /var/run.
In section 5.10 "/var/run : Run-time variable data", it says: "Programs
that maintain transient UNIX-domain sockets should place them in this
directory."
Peter Eisentraut [EMAIL PROTECTED] writes:
Perhaps there could be some sort of /etc/postgresql.conf file that is read
by both client and server that can control these sort of aspects.
Maybe ... but it seems to me that still leaves us with the issue of
a single pathname that must be known
Lamar Owen [EMAIL PROTECTED] writes:
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
How about an environment variable? PGSOCKLOC?
It's spelled PGHOST as of 7.1 ...
I'm talking about Unix domain socket location, not TCP/IP hostname,
which PGHOST is, right?
No, in 7.1 PGHOST serves
"Oliver Elphick" [EMAIL PROTECTED] writes:
No, UNIX sockets are specifically mentioned as belonging under /var/run.
In section 5.10 "/var/run : Run-time variable data", it says: "Programs
that maintain transient UNIX-domain sockets should place them in this
directory."
So what ever the
On Sun, 28 Jan 2001, Tom Lane wrote:
"Oliver Elphick" [EMAIL PROTECTED] writes:
No, UNIX sockets are specifically mentioned as belonging under /var/run.
In section 5.10 "/var/run : Run-time variable data", it says: "Programs
that maintain transient UNIX-domain sockets should place them in
The Hermit Hacker [EMAIL PROTECTED] writes:
Just curious here ... there seems to have been *alot* of energy expended
on this ... is there any reason why we don't just have a configuration
option like other software has, that defaults to /tmp like we have it now,
but that makes it easier for
On Sun, 28 Jan 2001, Bruce Momjian wrote:
The bottom line: yes, /tmp was a poor choice of place to put the
socket files. But no, it is not so poor as to be worth creating a
Was it really a poor choice. Where else can we put it as non-root?
~pgsql/var/run? everything else was under that
On Sun, 28 Jan 2001, Bruce Momjian wrote:
The bottom line: yes, /tmp was a poor choice of place to put the
socket files. But no, it is not so poor as to be worth creating a
Was it really a poor choice. Where else can we put it as non-root?
~pgsql/var/run? everything else was
Bruce Momjian [EMAIL PROTECTED] writes:
The bottom line: yes, /tmp was a poor choice of place to put the
socket files. But no, it is not so poor as to be worth creating a
Was it really a poor choice. Where else can we put it as non-root?
I would've favored something like
Bruce Momjian [EMAIL PROTECTED] writes:
The bottom line: yes, /tmp was a poor choice of place to put the
socket files. But no, it is not so poor as to be worth creating a
Was it really a poor choice. Where else can we put it as non-root?
I would've favored something like
Bruce Momjian wrote:
No one has suggested a location non-root people can put the socket/lock
file, except /tmp, and IMHO, until we find one, the default stays in
/tmp.
Since RPM's _must_ be installed by root, that doesn't affect them. The
debian packages are the same way. As long as
Lamar Owen [EMAIL PROTECTED] writes:
But my issue is that libpq or any other client should be smart enough to
not have to assume the location.
Er, how do you propose to do that? The client cannot learn the correct
location from the postmaster --- it must figure out *on its own* where
the
On Mon, 29 Jan 2001, Oliver Elphick wrote:
It seems to me that the main reason for the problem is the need to
cater for non-root installs. I would really like to know what
PostgreSQL will _not_ run as root. Just try... :)
morannon:~/usr/local/pgsql/bin/postmaster
"root" execution of the
"Dominic J. Eidson" wrote:
On Mon, 29 Jan 2001, Oliver Elphick wrote:
It seems to me that the main reason for the problem is the need to
cater for non-root installs. I would really like to know what
PostgreSQL will _not_ run as root. Just try... :)
I'm talking about the
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
But my issue is that libpq or any other client should be smart enough to
not have to assume the location.
Er, how do you propose to do that? The client cannot learn the correct
location from the postmaster --- it must figure out *on its
Lamar Owen [EMAIL PROTECTED] writes:
How does netstat find out?
netstat burrows around in kernel datastructures, is how.
I don't see invoking netstat as a solution anyway. For one thing,
it's drastically nonstandard; even if available, it varies in parameters
and output format (your "simple
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
How does netstat find out?
netstat burrows around in kernel datastructures, is how.
I don't see invoking netstat as a solution anyway. For one thing,
it's drastically nonstandard; even if available, it varies in parameters
I said as
On Fri, 26 Jan 2001, Peter Eisentraut wrote:
Bruce Momjian writes:
If we have to do it, let's make it an #ifdef __linux__ option.
What does Linux have to do with it? FreeBSD does the same thing, only
every three days. I dont' know whether it's not enabled on a fresh
install, but it's there,
/tmp is for *temporary* files. Such a lock is not a temporary file, it
should go somewhere in /var, why not in /var/lib/pgsql/data ?
The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock
file after the server has run 6 days. This will be a problem.
We could touch
Florent Guillaume wrote:
/tmp is for *temporary* files. Such a lock is not a temporary file, it
should go somewhere in /var, why not in /var/lib/pgsql/data ?
/var/lib is also not for locks, per FHS.
/var/lock/pgsql (or /var/lock/postgresql) would be the FHS-mandated
place for such a
first off, the lock file is put in by an unprivileged user, so /tmp works
on all systems ...
second, /tmp on a large portion of systems gets cleaned out after a
reboot, so there are no 'stray locks' to generally worry about...
On Sat, 27 Jan 2001, Lamar Owen wrote:
Florent Guillaume wrote:
The Hermit Hacker wrote:
On Sat, 27 Jan 2001, Lamar Owen wrote:
Comments? _Why_ is the lock in /tmp? Won't the lock always be put into
place by the uid used to run postmaster? Is a _world_ writeable
temporary directory the right place?
first off, the lock file is put in by an
Lamar Owen writes:
I understand why the socket needs to be in /tmp, but why the lockfile?
The lock file protects the Unix domain socket. Consequently, the name of
the lock file needs to be derivable from the name of the socket file, and
vice versa. Also, the name of the socket file must not
Peter Eisentraut wrote:
Lamar Owen writes:
I understand why the socket needs to be in /tmp, but why the lockfile?
The lock file protects the Unix domain socket. Consequently, the name of
the lock file needs to be derivable from the name of the socket file, and
vice versa. Also, the name
I understand why the socket needs to be in /tmp, but why the lockfile?
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to overcome if we want to move the
socket files. The
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to overcome if we want to move the
socket files. The location of the socket files is essentially a core
part of the
43 matches
Mail list logo
