From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dan Langille <dan(at)langille(dot)org> |
Cc: | am(at)fx(dot)ro, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postmaster.pid |
Date: | 2003-01-03 22:49:27 |
Message-ID: | 16722.1041634167@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dan Langille <dan(at)langille(dot)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.
It's worth noting that Postgres is not the only program with this issue.
Sendmail, for example, uses the same pidfile lock method, and I have
seen sendmail fail to restart after a system crash because it was fooled
by another process with matching pid.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-01-04 00:45:38 | Re: example table functions? |
Previous Message | Dan Langille | 2003-01-03 22:38:47 | Re: postmaster.pid |