| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | korry <korry(at)appx(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: file-locking and postmaster.pid |
| Date: | 2006-05-24 22:38:57 |
| Message-ID: | 20060524223857.GE7412@surnet.cl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
korry wrote:
> > > 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.
Well, you are wrong here. We _want_ every backend to hold a shared
lock. We need to stop a postmaster from starting if there is a backend
running that was started by a no-longer-running postmaster.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | korry | 2006-05-24 22:53:11 | Re: file-locking and postmaster.pid |
| Previous Message | Tom Lane | 2006-05-24 22:36:47 | Re: file-locking and postmaster.pid |