Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > Tom Lane wrote:
> >> Yeah, if you search the archives you will find previous discussions of
> >> how the check for a pre-existing postmaster could be made more resistant
> >> to false matches. It seems to be a hard problem to solve in a way
> >> that's both portable and 100% safe (while false positives are annoying,
> >> false negatives are completely not acceptable). AFAIR all the
> >> alternative methods that we've heard about have their own downsides.
>
> > I assume one of those alternatives was for the postmaster to open and
> > lock a predefined file in $PGDATA (say, postmaster.lock) using fcntl
> > or flock style locking?
>
> Yes, that was discussed. I think the primary objection was that it's
> very non-robust if the $PGDATA directory is mounted via NFS. (Quite
> a few of us think that if you run a database over NFS, you deserve to
> lose ;-( ... but there seem to be more than a few people out there doing
> it anyway.)
Oh, my stomach. I was afraid of that. If necessary you can put the
lock file elsewhere, I suppose...
> Also, the fact that you even had to mention two different ways of doing
> it is prima facie evidence that there are portability issues...
Well, that doesn't necessarily follow, but even if it did, we have
autoconf, we can very easily select a method as appropriate based on
the results of testing the platform from within configure (I mean,
what else is autoconf really for?). But my bet is that fcntl style
locking is supported on all the platforms PostgreSQL supports because
it's a POSIX.1 standard.
But even if fcntl locking isn't supported on all the platforms
PostgreSQL supports, it should be no harder a problem than which
method of syncing a file to disk to use...
--
Kevin Brown kevin@sysexperts.com