Re: F_SETLK is looking worse and worse...

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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.

Nor remove them?

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

I think this is a bad idea, because it assumes that the would-be
examiner (a) has read access to someone else's data directory, and
(b) has the same chroot setting as the someone else does (else the
symlink won't mean the same thing to both of them). UUNET was planning
to run postmasters chrooted into various subdirectories, IIRC, so
point (b) isn't hypothetical.

However, I have no objection to writing the value of DataDir into
the socket lockfile (along with the owner's PID) if that seems like
a worthwhile bit of info.

Would there be any value in having a postmaster re-read its own socket
lockfile every so often, to keep it looking active to /tmp sweepers?
Or is that too much of a kluge?

regards, tom lane