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@gmx.net http://yi.org/peter-e/