Re: postmaster.pid

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

In response to

Responses

Browse pgsql-general by date

  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