Tom Lane wrote:
> 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. #
#================================================== JanWieck@Yahoo.com #
