Re: postmaster.pid

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: postmaster.pid
Дата
Msg-id 11383.1041627827@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: postmaster.pid  (am@fx.ro)
Ответы Re: postmaster.pid  (Dan Langille <dan@langille.org>)
Re: postmaster.pid  (am@fx.ro)
Список pgsql-general
am@fx.ro writes:
> i think that somewhere in the docs the administators
> should be advised to delete postmaster.pid automatically at boot
> time ( for example at the same time when the files in /tmp are
> deleted ).
> This way, in case of an unexpected shutdown, postgresql would be
> able to restart without any manual intervention.

>> Well, this is a *BAD IDEA*. Suppose, for example, your data is corrupt in
>> some special way, an due to your removal of the pid file, postmaster tries to
>> recover the database automatically and probably destroys all or data part of
>> the data. You would like to have been able to do a filseystem level backup
>> first...

This is nonsense.  Removal of the postmaster.pid file won't make any
difference one way or the other to recoverability of the data.

> Ooopss...  it seems like i am too optimistic about such situations.

The real risk of having a script that automatically removes the
postmaster.pid file is that the script might get run after the
postmaster has started.

Even then, you're not necessarily hosed; but you no longer have any
protection against accidentally starting a second postmaster in the same
database directory.  (Which would be disastrous: the two postmasters
won't know about each other and will make unsynchronized changes in the
database.)

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.

If you can be absolutely certain that your script will *only* get run
early in system boot, then having it remove postmaster.pid is arguably
a reasonable thing to do.  (Putting "rm postmaster.pid" into the startup
script for the postmaster itself would not be reasonable, since you
might well use that script to restart the postmaster --- with the rm in
place, you've just fried the interlock against starting two postmasters.)

Whether the benefits outweigh the risks is up to you to decide.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: can't create type lo (BLOB)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Field with default not being set on copy from.