Re: F_SETLK is looking worse and worse...

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/