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
Re: postmaster.pid |
Список | 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 по дате отправления: