Re: How to shoot yourself in the foot: kill -9 postmaster
От | Thomas Swan |
---|---|
Тема | Re: How to shoot yourself in the foot: kill -9 postmaster |
Дата | |
Msg-id | 5.0.2.1.0.20010305171513.02527340@tangent.ics.olemiss.edu обсуждение исходный текст |
Ответ на | How to shoot yourself in the foot: kill -9 postmaster (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
At 3/5/2001 04:30 PM, you wrote: >Now, killing the postmaster -9 and not cleaning up the backends has >always been a good way to shoot yourself in the foot, but up to now the >worst thing that was likely to happen to you was isolated corruption in >specific tables. In the brave new world of WAL the stakes are higher, >because the system will refuse to start up if it finds a corrupted >checkpoint record. Clueless admins who resort to kill -9 as a routine >admin tool *will* lose their databases. Moreover, the init scripts >that are running around now are dangerous weapons if used with 7.1. > >I think we need a stronger interlock to prevent this scenario, but I'm >unsure what it should be. Ideas? Is there anyway to see if the other processes (child) have a lock on the log file? On a lot of systems, when a daemon starts, will record the PID in a file so it/'the admin' can do a 'shutdown' script with the PID listed. Can child processes list themselves like child.PID in a configurable directory, and have the starting process look for all of these and shut the "orphaned" child processes down? Just thoughts... Thomas
В списке pgsql-hackers по дате отправления: