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
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
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
"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
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
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 s
Bruce Momjian wrote:
> Lamar Owen wrote:
> > Bruce Momjian wrote:
> > > No one has suggested a location non-root people can put the socket/lock
> > Since RPM's _must_ be installed by root, that doesn't affect them. The
> The issue we have is that we don't assume root installs. Any root
> requir
Tom Lane wrote:
>Just out of curiosity, does Debian enforce a nonstandard location for
>X sockets as well?
X has a big exception made for it in the FHS for /usr/X11R6; I don't see
any mention of how /tmp/.X11/ is to be treated, but X isn't my problem!
I suspect no-one has ever thought to ask
> 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
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 the R
> 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 lik
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 /tmp/.postgr
> 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? everythin
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
> 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?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Lamar Owen <[EMAIL PROTECTED]> writes:
> Tom fixed the bug with a slight kludge -- by touching the lock
> periodically, the problem is ameliorated for now. But as long as we
> have a persistent file in /tmp we will run into OS-dependent problems.
> I can see now a bug report that PostgreSQL is u
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
> It has touched a nerve, hasn't it? I like your solution -- but, to
> reiterate, this IMHO is 7.2 material, unless we want to go the feature
> patch route, or someone considers this a 'bugfix' (I don't). Unless it
> is a trivial change, that is.
>
> Tom fixed the bug with a slight kludge -- by
The Hermit Hacker wrote:
> On Sun, 28 Jan 2001, Tom Lane wrote:
> > "Oliver Elphick" <[EMAIL PROTECTED]> writes:
> > > So what ever the outcome for the wider PostgreSQL community, I must make
> > > the change to conform to Debian policy.
> > Just out of curiosity, does Debian enforce a nonstandar
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
"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 t
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 PG
> 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
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
> > dir
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...
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, ri
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 wid
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
[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 store
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 wh
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 sam
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).
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 a-
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 somethi
[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 o
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 re
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...
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Trond Eivind Glomsrød 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 compati
Lamar Owen wrote:
>Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the
>sockets can go there by FHS, right?
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 trans
Lamar Owen <[EMAIL PROTECTED]> writes:
> Trond Eivind Glomsrød 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 compatibil
Trond Eivind Glomsrød 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
> > soc
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]
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> Not to sound scheptical, but since when did postgresql care about
> backwards compatiblity? Upgrading is already demanding a lot of
> knowledge from the user (including needing such information, which
> almost no other package
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.
Not to sound scheptical, but sin
> 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
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
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
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
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:
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 f
50 matches
Mail list logo
