I noticed while doing some debugging this morning that if the postmaster crashes for some reason (eg kill -9) the bgwriter process never goes away. Backends will eventually exit when their clients quit, and the stats collection processes shut down nicely, but the bgwriter process has to be killed by hand. This doesn't seem like a real good thing. Maybe there should be a provision similar to the stats collector's check-for-read-ready-from-a-pipe?
Hmmmm,
the case of the bgwriter is a bit of a twist here. In contrast to the collectors it is connected to the shared memory. So it can keep resources and also even worse, it could write() after the postmaster died.
Maybe there is a chance to create a watchdog for free here. Do we currently create our own process group, with all processes under the postmaster belonging to it? If the bgwriter would at the times it naps check if its parent process is init, (Win32 note, check if the postmaster does not exist any more instead), it could kill the entire process group on behalf of the dead postmaster. This is one more system call at a time, where the bgwriter does a system call with a timeout to nap anyway.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
