Re: Re: Sure enough, the lock file is gone

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