Re: [HACKERS] F_SETLK is looking worse and worse...

2000-12-10 Thread Peter Eisentraut
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

Re: [HACKERS] F_SETLK is looking worse and worse...

2000-12-09 Thread Bruce Momjian
> 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

Re: [HACKERS] F_SETLK is looking worse and worse...

2000-11-29 Thread Tom Lane
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

Re: [HACKERS] F_SETLK is looking worse and worse...

2000-11-29 Thread Peter Eisentraut
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

Re: AW: [HACKERS] F_SETLK is looking worse and worse...

2000-11-29 Thread Tom Lane
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

Re: [HACKERS] F_SETLK is looking worse and worse...

2000-11-29 Thread Tom Lane
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

Re: [HACKERS] F_SETLK is looking worse and worse...

2000-11-29 Thread Matthew Kirkwood
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

AW: [HACKERS] F_SETLK is looking worse and worse...

2000-11-29 Thread Zeugswetter Andreas SB
> 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

[HACKERS] F_SETLK is looking worse and worse...

2000-11-28 Thread Tom Lane
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