Sorry for jumping in late on this...
Tom Lane wrote:
> Dan Langille <dan@langille.org> writes:
> > On Fri, 3 Jan 2003, Tom Lane wrote:
> >> Note also that under most circumstances, a stale postmaster.pid file
> >> should not prevent the postmaster from starting (because it will ignore
> >> the old .pid file if it can see that there is no process with that PID
> >> alive anymore). The case where you lose is only when there is another
> >> process running that by chance has the same PID that was assigned to the
> >> old postmaster on the system's previous uptime cycle. The postmaster
> >> can't tell that such a process isn't really a conflicting postmaster,
> >> so it gives up for safety's sake.
>
> > This is a situation which I've often wondered about, for other scripts,
> > not PostgreSQL. I've not found a happy solution yet.
>
> 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? File locking is such a basic service that I
can't imagine any of the OSes PostgreSQL currently supports not
supporting it.
PID files are useful for administrative purposes but the various Unix
tricks used to "lock" and serialize access to files (hard links, for
instance) are (or should be!) no longer necessary. Fcntl locking is
specified in POSIX.1 (or so says the Linux fcntl(2) manpage), so
that's what I'd go with by default.
Since only one postmaster can run per $PGDATA directory, it seems
reasonable to have the postmaster obtain an exclusive lock on a file
(via fcntl or flock on Unix platforms) in that directory. No need to
explicitly unlock the file on exit, either: the OS will take care of
that (the OS is broken if it doesn't). If it fails to acquire the
lock, then another postmaster must be running. The only way to
sabotage this mechanism is by deleting the lock file, which is why it
would be desirable to obtain a lock on the $PGDATA directory itself if
possible and reasonable.
Thoughts?
--
Kevin Brown kevin@sysexperts.com
