Re: postmaster.pid

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: postmaster.pid
Дата
Msg-id 16722.1041634167@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: postmaster.pid  (Dan Langille <dan@langille.org>)
Ответы Re: postmaster.pid  (Kevin Brown <kevin@sysexperts.com>)
Список pgsql-general
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.

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

В списке pgsql-general по дате отправления:

Предыдущее
От: Dan Langille
Дата:
Сообщение: Re: postmaster.pid
Следующее
От: Joe Conway
Дата:
Сообщение: Re: example table functions?