Sure enough, the lock file is gone

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 (open) the file once every time the ServerLoop() runs
around. It's not perfect but it should work in practice.

If we have to do it, let's make it an #ifdef __linux__ option.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote:

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 (open) the file once every time the ServerLoop() runs
around. It's not perfect but it should work in practice.

If we have to do it, let's make it an #ifdef __linux__ option.

#ifdef BRAINDAMAGED_TMP_CLEANER ?

ISTR mention of non-linux platforms that do this.

Ross

* Peter Eisentraut <peter_e@gmx.net> [010126 12:11] wrote:

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 (open) the file once every time the ServerLoop() runs
around. It's not perfect but it should work in practice.

Why not have the RPM/configure scripts stick it in where ever redhat
says it's safe to?

--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Ross J. Reedstrom wrote:

On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote:

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 (open) the file once every time the ServerLoop() runs
around. It's not perfect but it should work in practice.

If we have to do it, let's make it an #ifdef __linux__ option.

#ifdef BRAINDAMAGED_TMP_CLEANER ?

ISTR mention of non-linux platforms that do this.

Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.

Better use utime(2) or the like for it.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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, you only need to flip the switch. I doubt /tmp
cleaning is such an unusual thing, especially on large sites.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Jan Wieck writes:

Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.

The lock file is an ordinary file.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.net> writes:

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, you only need to flip the switch. I doubt /tmp
cleaning is such an unusual thing, especially on large sites.

Yes, there are lots of systems that will clean /tmp --- and since the
lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
is going to decide to remove it. I think that I had intended to insert
a periodic touch of the lockfile and forgot to.

Touching it every time through ServerLoop is an overreaction though.
I'd suggest touching it in the checkpoint-process-firing code, which
runs every five minutes (or so?) by default.

regards, tom lane

Peter Eisentraut wrote:

Jan Wieck writes:

Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.

The lock file is an ordinary file.

So the crazy-temp-vacuum-cleaner on linux doesn't touch the
sockets?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

I said:

Yes, there are lots of systems that will clean /tmp --- and since the
lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
is going to decide to remove it. I think that I had intended to insert
a periodic touch of the lockfile and forgot to.

Done now.

regards, tom lane

On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote:

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 (open) the file once every time the ServerLoop() runs
around. It's not perfect but it should work in practice.

If we have to do it, let's make it an #ifdef __linux__ option.

#ifdef BRAINDAMAGED_TMP_CLEANER ?

ISTR mention of non-linux platforms that do this.

Yes, thank you.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

I said:

Yes, there are lots of systems that will clean /tmp --- and since the
lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
is going to decide to remove it. I think that I had intended to insert
a periodic touch of the lockfile and forgot to.

Done now.

Yes, checkpoint is a good place to put it. Thanks. I still liked the
BRAINDAMAGED_TMP_CLEANER though.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

On Fri, Jan 26, 2001 at 05:06:24PM -0500, Jan Wieck wrote:

So the crazy-temp-vacuum-cleaner on linux doesn't touch the
sockets?

The tmpwatch program that comes with many Linux distributions will only
unlink regular files and empty directories by default.
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/

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, you only need to flip the switch. I doubt /tmp
cleaning is such an unusual thing, especially on large sites.

Only on a poorly configured FreeBSD box. You do have to turn it on first.
FreeBSD (This is a 4.2-Stable box) will only delete files that have not been
modified within the set number of days. This amount is variable. You can also
tell clean_tmp to ignore any files you wish. This is all configurable via
rc.conf and friends.

GB

--
GB Clark II | Roaming FreeBSD Admin
gclarkii@GeekTech.COM | General Geek
CTHULU for President - Why choose the lesser of two evils?

Jan Wieck wrote:

Peter Eisentraut wrote:

Jan Wieck writes:

Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.

The lock file is an ordinary file.

So the crazy-temp-vacuum-cleaner on linux doesn't touch the
sockets?

tmpreaper does - that's why I moved the socket in Debian.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Come now, and let us reason together, saith the LORD;
though your sins be as scarlet, they shall be as white
as snow; though they be red like crimson, they shall
be as wool." Isaiah 1:18

/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 ?

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 alessio@sevenseas.org

Jan Wieck wrote:

Peter Eisentraut wrote:

Jan Wieck writes:

Exactly the way you want it to do (open(2) and close(2) of a
UNIX domain socket) was what I had to do to get an old
Mach3-4.3BSD combo into a kernel-panic.

The lock file is an ordinary file.

So the crazy-temp-vacuum-cleaner on linux doesn't touch the
sockets?

tmpreaper does - that's why I moved the socket in Debian.

But you have complete control over the OS, while we don't. The problem
I see of moving it is that only Debian-compiled clients will work on
Debian systems.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

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?

7.2 discussion, however, IMHO.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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:

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

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?

7.2 discussion, however, IMHO.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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 unprivileged user, so /tmp works
on all systems ...

If /usr/local/pgsql (to use the default) is owned by the user running
postmaster, then the postmaster has privileges to put the lockfile in,
say, /usr/local/pgsql/lock/....., right? Or am I missing something basic
here? Is this lock placed by postmaster, or by something else? My
7.1beta3 installation shows two files in /tmp:
srwxrwxrwx 1 postgres postgres 0 Jan 27 14:25 .s.PGSQL.5432
-rw------- 1 postgres postgres 25 Jan 27 14:25
.s.PGSQL.5432.lock

I understand why the socket needs to be in /tmp, but why the lockfile?
What or who is using the lockfile (which contains the pid of postmaster
and the path to PGDATA for the postmaster)?

second, /tmp on a large portion of systems gets cleaned out after a
reboot, so there are no 'stray locks' to generally worry about...

Ironic that RedHat, which can clean /tmp out on a cron basis would be
one that doesn't clean it out by default on reboot.

Lock file cleanup should be the responsibility of the script that starts
postmaster -- or the responsibility of the DBA who manually starts and
restarts postmasters, after crashes or at other times.

Not a big issue, by any means. Just attempting to understand.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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 of the socket file must not vary with other
parameters such as installation layout.

I see.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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 vary with other
parameters such as installation layout.

Lock file cleanup should be the responsibility of the script that starts
postmaster

The postmaster does that itself. That's why the pid is in there.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

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 location of the socket files is essentially a core
part of the frontend-backend protocol, because both client and server
must know it ab initio. Move the socket, break your clients.

There is an option in 7.1 to support defining a different directory
for the socket files, but I doubt very many people will use it.

I see no real good reason to keep the lockfiles in a different place
from the sockets themselves, however. Doing so would just complicate
things even more, without adding any real safety or security.

regards, tom lane

Bruce Momjian wrote:

Note: programs that run as non-root users may be unable to create files un

der

/var/run and therefore need a subdirectory owned by the appropriate user.

This is the killer. We can't require root. Seems we are stuck with
/tmp.

I'd be surprised to learn that non-admin users are allowed to write
in /usr/local, either. If, on some machine, PostgreSQL is such an
unoffical project that the admin won't agree to create /var/run/postgresql,
the user can define his own temporary directory using the method we have
already included in 7.1; if, on the other hand, he is able to create
/usr/local/pgsql, he will also be able to create /var/run/postgresql.

Really, how many users do we have who can't get their admin to do
this for them?

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Come now, and let us reason together, saith the LORD;
though your sins be as scarlet, they shall be as white
as snow; though they be red like crimson, they shall
be as wool." Isaiah 1:18

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 frontend-backend protocol, because both client and server
must know it ab initio. Move the socket, break your clients.

Ok, fair enough.

But sometimes unix sucks, don't you think, having to use /tmp as a
central place for inter-process communication... blech.

Florent

--
<florent.guillaume@mail.com>

"Oliver Elphick" <olly@lfix.co.uk> writes:

/var/run/postgresql

There's another reason why the standard socket directory is /tmp,
and that's that it exists everywhere. Not all Unix systems even *have*
a /var hierarchy, let alone one that the admin will let you have a
playpen in.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> 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 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 do), this is just a minor change (the files
are mostly used by bundled tools - any exceptions?)

There is an option in 7.1 to support defining a different directory
for the socket files, but I doubt very many people will use it.

I intend to, for the RPMs we ship.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

teg@redhat.com (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 do), this is just a minor change (the files
are mostly used by bundled tools - any exceptions?)

It is not a minor change. Pay attention now: moving the socket files
BREAKS THE CLIENT/SERVER PROTOCOL. Got that? If you do this, then
no old client program will work against your new server until you
recompile/relink it.

Don't forget, also, that clients built using the standard distribution
won't talk to your server either. Unless you have *sole* control of
Postgres and Postgres clients on your machine, moving the socket files
is going to create problems.

We have seen enough complaints in the past due to changes in the
protocol (all of which were backwards-compatible, BTW; this isn't)
that I'm pretty hesitant to do another one on such minor grounds as
getting the socket file out of /tmp.

There is an option in 7.1 to support defining a different directory
for the socket files, but I doubt very many people will use it.

I intend to, for the RPMs we ship.

Expect complaints.

I wouldn't be so annoyed at this, if I didn't know very well that the
resulting questions/complaints will come to the Postgres team, and not
to the perpetrator of the incompatibility. Shall I forward all future
"can't connect to server" bug reports to you to answer?

regards, tom lane

Trond Eivind Glomsr�d wrote:

Tom Lane <tgl@sss.pgh.pa.us> 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 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 do), this is just a minor change (the files
are mostly used by bundled tools - any exceptions?)

Upgrading is only one facet of backwards compatibility. When the fe-be
protocol was changed for 6.4.2 is a good example. The SQL itself is
kept very backwards-compatible, on purpose. Things for
backwards-compatibility are not as bad as the upgrading situation would
seem to imply.

There is an option in 7.1 to support defining a different directory
for the socket files, but I doubt very many people will use it.

I intend to, for the RPMs we ship.

Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the
sockets can go there by FHS, right? Of course, our requirement that
they be in the same location sort of forces the issue. But, 7.1 now
touches the locks enought to keep tmpwatch from blowing them out.

To where do you intend to move them to? /var/lock/pgsql?
/var/run/pgsql? (Or postgresql... I'm still not happy with that change
-- the configuration is much nicer, but now the 'postgresql' suffix is
fixed -- I'm probably going to have to patch that to pgsql, as I'm
already changing many things that I'd prefer to leave closer to what 7.0
had).

The change in question is the use of '/usr/share/postgresql' and
'/usr/include/postgresql' as part of the installation, rather than
allowing '/usr/share/pgsql' and '/usr/include/pgsql' .

O well -- I'm just going to have to see how it distills. I've not
received any complaints yet, but I expect many after final. :-(
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:

Trond Eivind Glomsr�d wrote:

Tom Lane <tgl@sss.pgh.pa.us> 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 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 do), this is just a minor change (the files
are mostly used by bundled tools - any exceptions?)

Upgrading is only one facet of backwards compatibility.

I know. I just mentioned one consistently painful aspect of it.

There is an option in 7.1 to support defining a different directory
for the socket files, but I doubt very many people will use it.

I intend to, for the RPMs we ship.

Ok, why not fix tmpwatch instead?

Because it wouldn't be a fix, it would be a "lets workaround one
specific app which does things in a bad way"-hack. /tmp isn't supposed
be more than that... storing things there for more than than 10 days?
Ouch.

Only the lock files break FHS

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

To where do you intend to move them to? /var/lock/pgsql?
/var/run/pgsql?

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

--
Trond Eivind Glomsr�d
Red Hat, Inc.

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 transient UNIX-domain sockets should place them in this
directory."

So what ever the outcome for the wider PostgreSQL community, I must make
the change to conform to Debian policy.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Many are the afflictions of the righteous; but the
LORD delivereth him out of them all."
Psalm 34:19

Trond Eivind Glomsr�d wrote:

Lamar Owen <lamar.owen@wgcr.org> 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 compatibility.

I know. I just mentioned one consistently painful aspect of it.

Your pain is evident from the hyperbolic statement. I share your pain.

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

But postmaster _doesn't_ expect the files to stay _between_
invocations.... :-) But your point is understood.

What about the X sockets, then? X might stay up 10+ days. X doesn't
just put one file there, either -- there's a whole directory there in
/tmp.

To where do you intend to move them to? /var/lock/pgsql?
/var/run/pgsql?

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

According to what Peter said, that could be difficult.

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

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 else?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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

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. But I
don't see much use in it besides port number and socket location.
Because those are, by definition, the only parameters in common to client
and server.

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?

Yes. Good point.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

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 both client and server that can control these sort of aspects. But I
don't see much use in it besides port number and socket location.
Because those are, by definition, the only parameters in common to client
and server.

Of course, -i and TCP/IP to localhost obviate all of this.

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.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

teg@redhat.com (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 of the specific features
that UUNET asked us for. Namely, to be able to have noninterfering
sets of socket files in different explicitly-specified directories.
If the lock files don't live where the sockets do, then this doesn't work.

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 /tmp "between invocations".
The socket and lock file live only as long as the postmaster runs.

regards, tom lane

Lamar Owen <lamar.owen@wgcr.org> 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 else?

As the 7.1 code presently stands, libpq contains a compiled-in default
socketfile location, which the client code hopefully doesn't know about.
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. However, the pitfalls should be obvious: independently built
clients, statically linked libraries, differing .so version numbers
to name three risk areas.

regards, tom lane

Peter Eisentraut <peter_e@gmx.net> 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-priori to both client and server.
You've just changed that path from "/tmp/..." to "/etc/...".

Moreover, such a setup would make it substantially more painful to run
multiple versions of Postgres on a single machine. Right now, as long
as each version has a different default port number, it works great.
Try to put the default port number in /etc/postgresql.conf, and you've
got a problem.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

teg@redhat.com (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 that you AFAIK (I don't use mysql much, I prefer postgresql) can
have multiple sections if you want want to have multiple backends
running.

That is not "ideal", in fact it would break one of the specific features
that UUNET asked us for. Namely, to be able to have noninterfering
sets of socket files in different explicitly-specified directories.
If the lock files don't live where the sockets do, then this doesn't
work.

I don't see why this must be so...

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 /tmp "between invocations".

Between invocations of client programs. You're using /tmp as a shared
of stored data.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Lamar Owen <lamar.owen@wgcr.org> 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
the default behavior of an installation will be, not what you can
override it to do.

regards, tom lane

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
'non-standard' as the libpq.so is likely to be from the same build or
package as the server is.

However, the pitfalls should be obvious: independently built
clients, statically linked libraries, differing .so version numbers
to name three risk areas.

These are real risks, of course. I have personal experience with the
statically linked client and differing so version number cases.

And, yes, to echo your previous sentiment, if it breaks, the
distributor/packager is not the one that gets the compliants -- the
PostgreSQL community does.

So, for future discussion, a compromise will have to be arranged -- but
this really isn't a 7.1 issue, as this isn't a 'bugfix' per se -- you
have fixed the immediate problem. But this is something to consider for
7.2 or later, as priorities are shuffled.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

teg@redhat.com (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 /tmp "between invocations".

Between invocations of client programs. You're using /tmp as a shared
of stored data.

Huh? The socket and lockfile are created and held open by the
postmaster for the duration of its run. Client programs don't even know
that the lockfile is there, in fact. How can you argue that client
program lifespan has anything to do with it?

regards, tom lane

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> 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
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?

But you are very right -- this doesn't help the default. The
FHS-mandated place for such a configuration file detailing such settings
is in /etc -- but, of course, we support installations that have been
installed by a non-root user. ISTM a 'pg_config --default-socket'
command could be used to find the location, assuming pg_config is on the
PATH.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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 PostgreSQL community, I must make
the change to conform to Debian policy.

So, if PostgreSQL is a part of Debian, then there will be problems if
the client-server situation isn't somehow fixed to allow robust
location-independent socket finding.

Looks like the same thing is going to happen with RedHat's
distribution. So, if this is going to occur, let's get a consensus as
to where that alternate location (barring some other solution) is going
to be, so that there are the fewest variants out there.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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?

Found the code in fe-connect.c that changes that assumption.....sorry
for my high density :-).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> 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."

So what ever the outcome for the wider PostgreSQL community, I must make
the change to conform to Debian policy.

So, if PostgreSQL is a part of Debian, then there will be problems if
the client-server situation isn't somehow fixed to allow robust
location-independent socket finding.

Looks like the same thing is going to happen with RedHat's
distribution. So, if this is going to occur, let's get a consensus as
to where that alternate location (barring some other solution) is going
to be, so that there are the fewest variants out there.

FHS is a good starting (and end-) point.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Tom Lane <tgl@sss.pgh.pa.us> writes:

teg@redhat.com (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 /tmp "between invocations".

Between invocations of client programs. You're using /tmp as a shared
of stored data.

Huh? The socket and lockfile are created and held open by the
postmaster for the duration of its run. Client programs don't even know
that the lockfile is there, in fact. How can you argue that client
program lifespan has anything to do with it?

Nothing but the postmaster uses it? If so, there shouldn't be a
problem moving it.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

Peter Eisentraut <peter_e@gmx.net> 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-priori to both client and server.
You've just changed that path from "/tmp/..." to "/etc/...".

And writing to /etc requires root permissions. That is the restriction
that got us into /tmp in the first place.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Lamar Owen <lamar.owen@wgcr.org> writes:

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> 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 a dual purpose. If a hostname beginning with
"/" is given, it's taken to specify Unix-socket communication using a
socketfile in the directory whose absolute path is PGHOST. A tad crocky
but it avoided having to add an additional parameter to the PQconnect
family of functions ...

Also, on the postmaster side, there is a postmaster commandline
parameter to set the directory containing the socket files (and
lockfiles). So it's possible for a given installation to configure
the socketfiles anywhere without modifying the binaries at all.
But you do need to set PGHOST on the client side to make this work.
It all comes back to what the default is.

Basically, what's bothering me is the idea that the RPM distribution
will have a different default socket location than the regular source
distribution. I think that will cause a lot more problems than it
solves.

regards, tom lane

"Oliver Elphick" <olly@lfix.co.uk> 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 outcome for the wider PostgreSQL community, I must make
the change to conform to Debian policy.

Just out of curiosity, does Debian enforce a nonstandard location for
X sockets as well?

regards, tom lane

On Sun, 28 Jan 2001, Tom Lane wrote:

"Oliver Elphick" <olly@lfix.co.uk> 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 outcome for the wider PostgreSQL community, I must make
the change to conform to Debian policy.

Just out of curiosity, does Debian enforce a nonstandard location for
X sockets as well?

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 others to change it for their installs, as
required?

The Hermit Hacker wrote:

On Sun, 28 Jan 2001, Tom Lane wrote:

"Oliver Elphick" <olly@lfix.co.uk> 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 nonstandard location for
X sockets as well?

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 others to change it for their installs, as
required?

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 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 unreliable because it
keeps crashing every x days (due to a tmpreaper-like program the hapless
user doesn't know is running in cron....).

Since pg_config already reports what configure options were provided, if
this is a configure option then the end user can easily find it with
pg_config, if a static linkage or binary-only custom client that
directly accesses the fe-be protocol (are there any that we know
about?).

But we don't need to spend a great deal of time on it, regardless.
Speaking of time to spend, are we a 'go' for beta4 yet? ETA? (so I can
budget time to rebuild RPM's).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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 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 unreliable because it
keeps crashing every x days (due to a tmpreaper-like program the hapless
user doesn't know is running in cron....).

Since pg_config already reports what configure options were provided, if
this is a configure option then the end user can easily find it with
pg_config, if a static linkage or binary-only custom client that
directly accesses the fe-be protocol (are there any that we know
about?).

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

The Hermit Hacker <scrappy@hub.org> 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 others to change it for their installs, as
required?

We *have* such a configuration option, both compile-time and run-time,
as of 7.1. The argument is about what the default should be, and in
particular whether it's a good idea for certain binary distributions to
have a different default than other distributions ...

regards, tom lane

Lamar Owen <lamar.owen@wgcr.org> 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 unreliable because it
keeps crashing every x days

Kindly don't exaggerate the importance of this problem. We've been
running systems with the socketfiles in /tmp for years now, and we
know quite well what the downsides of that are. They're not that
drastic (unless you run a tmp-sweeper too stupid to distinguish socket
files from plain files, and even then you only see failure to connect).

Addition of the socket lockfile to the mix isn't increasing the risks
measurably that I can see. Even if a tmp-sweeper is enthusiastic enough
to remove a lockfile that the postmaster touches every few minutes, so
what? Client connections don't depend on the lockfile. The lockfile
only exists to protect against admin error, ie, starting a second
postmaster on the same socket --- which in routine operation won't
happen anyway.

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
compatibility problem to fix it. Perhaps someday we will switch to
a whole new interface protocol (CORBA or whatever floats your boat),
and then we can let the whole mess drift off into the sunset. But
right now, there is almost nothing about our FE/BE protocol that
*isn't* a legacy decision --- and fixing it piecemeal at the cost of
a flag day for each fix is not worthwhile. IMHO anyway.

regards, tom lane

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
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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

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

Sure, but how do we hard-code where ~pgsql is located, unless we somehow
check the home directory of pgsql, but then again, they really don't
have to use the home directory of pgsql for the pgsql directory.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> 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/.postgres/socketfile,
which is comparable to typical X11 setups. But it's moot, since
we can't change the default path even that much without creating a
compatibility headache ...

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> 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/.postgres/socketfile,
which is comparable to typical X11 setups. But it's moot, since
we can't change the default path even that much without creating a
compatibility headache ...

Agreed, that would have been better, but I don't see that buys us
anything against the grim reaper.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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 RPM contains the
structures set as owned by 'postgres' (the default run user for
postmaster), and the appropriate permissions are set, the directory
could be anywhere, such as /var/run/pgsql. But there are of course
problems with that approach, because libpq makes some hard-coded
assumptions about where to look.

I have no problem with the default being in /tmp, just like I have no
problem with the default source installation being in /usr/local. But I
do think that the code should be smart enough to handle non-default
settings without major problems.

And I'll kindly not exaggerate the importance -- but I would have seen
reports had the simple fix not been applied.

But I'm not going to spend any more time arguing about it, that much is
certain. I've got other fish to fry, like beta4 RPM's.....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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 RPM contains the
structures set as owned by 'postgres' (the default run user for
postmaster), and the appropriate permissions are set, the directory
could be anywhere, such as /var/run/pgsql. But there are of course
problems with that approach, because libpq makes some hard-coded
assumptions about where to look.

The issue we have is that we don't assume root installs. Any root
requirement is going to be RPM-specific.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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 the question! You may be
pleased to know that I have now stirred the coals and asked that
question, which applies not only to X but also to several other programs
that I have running.

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
proportion of total PostgreSQL installs they now are. We are
a long way now from the days when Postgres was a research database with
a poor reputation for reliability. It is now becoming a serious
competitor to major commercial databases and will in many cases be
used as a major application on the machines where it is installed.

Are there still people who can only install PostgreSQL as a private
application?

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"My son, if sinners entice thee, consent thou not."
Proverbs 1:10

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
requirement is going to be RPM-specific.

[waiting on another RPM build cycle to finish]

I understand that issue. The RPMset is just not affected by that issue,
as, for an RPM to be installed, you must be root. No ifs ands or buts
-- an RPM installation assumes root, and can do anything along those
lines it needs to do.

Of course, that means I have to be extra careful -- people installing
RPM's I build are going to be running my %pre, %post, %preun, and
%postun scripts _as_root_. RPM's are quite capable of royally hosing a
system, if the packager hasn't done his homework. But that also means
malicious RPMs are possible (horrors.) -- one header in an RPM, hidden
from view, could render your system totally useless. Yes, it's true.
No, I won't package an RPM 'bomb' -- but it could be done, easily
enough.

Now, you can _build_ an RPM (which will be installed as root) as a
non-root user, and that invokes the 'make install' as part of its
process, but I digress (badly, at that).

But my issue is that libpq or any other client should be smart enough to
not have to assume the location.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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 PostgreSQL backend is not permitted.

The backend must be started under its own userid to prevent
a possible system security compromise. See the INSTALL file for
more information on how to properly start the postmaster.

morannon:~>

proportion of total PostgreSQL installs they now are. We are

100%

Are there still people who can only install PostgreSQL as a private
application?

Private application - or non-root application?

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

Lamar Owen <lamar.owen@wgcr.org> 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 socket file is. AFAICS you can't avoid having hardwired knowledge
about how to do that in the client.

You or somebody else previously suggested hardwiring the location of
a configuration file, rather than the socketfile itself, but I can't
see that that really improves matters in this context. In particular,
changing to such a method would still break backwards compatibility.

regards, tom lane

"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 installation, not execution.

By default, PostgreSQL will install in /usr/local/pgsql; most people
will need root privilege to create that directory.

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"My son, if sinners entice thee, consent thou not."
Proverbs 1:10

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> 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 socket file is. AFAICS you can't avoid having hardwired knowledge
about how to do that in the client.

How does netstat find out? A simple
netstat -a --unix|grep \.s\.PGSQL
will get the full list of all postmaster sockets. A little 'cut' or
'awk' work is simple enough.

I realize, of course, that netstat (and the underlying, on Linux,
/proc/net/unix file) is not portable. On Linux, simply grep
/proc/net/unix for the .s.PGSQL pattern and get the last column (or the
column before that, with the inode information).

Is there a portable way of listing the open unix domain sockets in this
manner, then deducing from the socket path what you need to know?

You or somebody else previously suggested hardwiring the location of
a configuration file, rather than the socketfile itself, but I can't
see that that really improves matters in this context. In particular,
changing to such a method would still break backwards compatibility.

Not me. The less hardwiring, the better, IMHO. And I'm glad you pointed
me to the new (undocumented that I could find) usage of PGHOST. A
dynamic socket finder (assuming no specific socket path has been passed)
would not break backwards compatibility, as it would find the default
/tmp case.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> 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 example" draws a usage complaint on my
box). Furthermore, a moderately security-conscious admin would probably
choose to make netstat unavailable to unprivileged users, since it
reveals an uncomfortably large amount about the activity of other users.
A final complaint is that netstat would actually reveal *too much*
information, since a netstat-based client would have no way to choose
among multiple postmasters. (Please recall that one of the motivations
for the UUNET patch was to allow multiple postmasters running with the
same port number in different subdirectories. Hmm, I wonder how netstat
shows socketfiles that are in chroot'd subtrees, or outside your own
chroot ...)

regards, tom lane

Tom Lane wrote:

Lamar Owen <lamar.owen@wgcr.org> 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 much as it wasn't portable. But I asked also if a portable
way was available -- I do not currently know that answer to that, but I
will be investigating such.

(Please recall that one of the motivations
for the UUNET patch was to allow multiple postmasters running with the
same port number in different subdirectories. Hmm, I wonder how netstat
shows socketfiles that are in chroot'd subtrees, or outside your own
chroot ...)

When were these 'UUNET' patches issued? I like the idea, but just
curious. I don't recall them, in fact -- nor do I recall the
discussion. I'll look it up in the archives later. Going to bed after a
night of RPM'ing.

As to the chroot vs netstat question, that is a good one. I have no
chroot's in effect, so I can't test that one.

So, if multiple postmasters are running on the same port in different
dirs, it would be somewhat difficult to determine which should be the
'default' in the list. However, one would think an admin who has set up
a multiple postmaster system of that sort wouldn't be relying on a
default anyway -- but that is a dangerous assumption.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Fri, Jan 26, 2001 at 11:55:16PM -0500, Bruce Momjian wrote:

I said:

Yes, there are lots of systems that will clean /tmp --- and since the
lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
is going to decide to remove it. I think that I had intended to insert
a periodic touch of the lockfile and forgot to.

Done now.

Yes, checkpoint is a good place to put it. Thanks. I still liked the
BRAINDAMAGED_TMP_CLEANER though.

Well, from reading the rest of the thread, it seems that, while tmpreaper
_is_, in fact, brain damaged (it'll eat socket files) that wasn't what we
were talking about: removal of apparently stale ordinary files, like our
lockfile, is what tmp cleaners are all about, even if it is problematic.

Personally, I've always thought tmp cleaners are a bad idea, a bandaid
approach to cleaning up after poorly written software: i.e. broken by
design. Well, it's resolved now, for pgsql. Can't fix all the software
out there, I guess.

Ross