Bruce Momjian writes:
> Removing 10-day-old files from /tmp seems pretty broken to me, and I
> hate to code around broken stuff.
(It's not 10-day-old files, it's files that have not been used for 10
days.)
But both the Linux file system standard and POSIX 2 have requirements
and/or recommendati
> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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?
> T
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 t
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> BTW, it also seems like a good idea to reorder the postmaster's
>> startup operations so that the data-directory lockfile is checked
>> before trying to acquire the port lockfile, instead of after. That
>> way, in the common scenario where you
Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> Surely the lock file could easily go somewhere other than
> /tmp, since it won't be breaking existing setups?
Such as where?
Given the fact that the recent UUNET patch allows the DBA to put the
socket files anywhere, it seems simplest to say that th
On Tue, 28 Nov 2000, Tom Lane wrote:
> That is, if the socket file name is /tmp/.s.PGSQL.5432, we'd create a
> plain file /tmp/.s.PGSQL.5432.lock
> 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
> BTW, it also seems like a good idea to reorder the postmaster's
> startup operations so that the data-directory lockfile is checked
> before trying to acquire the port lockfile, instead of after. That
> way, in the common scenario where you're trying to start a second
> postmaster in the same
While testing interlocking of multiple postmasters, I discovered that
the HAVE_FCNTL_SETLK interlock code we have in StreamServerPort()
does not work at all on HPUX 10.20. This platform has F_SETLK according
to configure, but:
1. The lock is never applied to a socket, because the open() on the
n