| From: | korry <korry(at)appx(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: file-locking and postmaster.pid |
| Date: | 2006-05-24 22:34:30 |
| Message-ID: | 1148510070.21335.97.camel@sakai.localdomain |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > You never need to reduce it to a shared lock. On postmaster startup,
> > try to lock the sentinel byte (one byte past the end-of-file). If you
> > can lock it, you know that no other postmaster has that byte locked. If
> > you can't lock it, another postmaster is running. It is an atomic
> > operation.
>
> This doesn't work if the postmaster dies but a backend continues to run,
> which is arguably the most important case we need to protect against.
I may be confused here, but I don't see the problem - byte-range locks
are not inherited across a fork. A backend would never hold the lock, a
backend would never even look for the lock.
> > However, Tom may be correct about NFS locking, but I guess I'm surprised
> > that anyone would care :-)
>
> Quite a lot of people run NFS-mounted data directories ...
I'm happy to take your word for that, and I agree that if NFS is
important and locking is brain-dead on NFS, then relying solely on a
lock is unacceptable.
-- Korry
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-05-24 22:36:47 | Re: file-locking and postmaster.pid |
| Previous Message | korry | 2006-05-24 22:21:14 | Re: file-locking and postmaster.pid |