From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: F_SETLK is looking worse and worse... |
Date: | 2000-11-29 16:37:31 |
Message-ID: | Pine.LNX.4.21.0011291731510.796-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane writes:
> I can only think of one scenario where this is worse than what we have
> now: if someone is running a /tmp-directory-sweeper that is bright
> enough not to remove socket files, it would still zap the interlock
> file, thus potentially allowing a second postmaster to take over the
> socket file. This doesn't seem like a mainstream problem though.
Red Hat by default cleans out all files under /tmp and subdirectories that
haven't been accesses for 10 days. I assume other Linux distributions do
similar things. Red Hat's tmpwatch doesn't ever follow symlinks, though.
That means you could make /tmp/.s.PGSQL.5432.lock a symlink to
PGDATA/postmaster.pid. That might be a good idea in general, since
establishes an easy to examine correspondence between data directory and
port number.
--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-11-29 16:53:13 | Re: F_SETLK is looking worse and worse... |
Previous Message | Peter Eisentraut | 2000-11-29 16:31:12 | Re: Initdb not running on beos |