Re: postmaster.pid
От | Kevin Brown |
---|---|
Тема | Re: postmaster.pid |
Дата | |
Msg-id | 20030121044939.GA12991@filer обсуждение исходный текст |
Ответ на | Re: postmaster.pid (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: postmaster.pid
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: