> > I don't think we want that. IMHO the preferred behavior if the
> > postmaster crashes should be like a "smart shutdown" --- you don't spawn
> > any more backends (obviously) but existing backends should be allowed to
> > run until their clients exit. That's how things have always worked
> > anyway...
> >
> > [ thinks ... ] If we do want it we don't need any process-group
> > assumptions. The bgwriter is connected to shmem so it can scan the
> > PGPROC array and issue kill() against each sibling.
>
> Right. Which can change the backend behaviour from a smart shutdown to
> an immediate shutdown. In the case of a postmaster crash, I think
> something in the system is so wrong that I'd prefer an immediate shutdown.
I agree that if the postmaster dies something bad is definately happening.
However, there will be a period of time X between the postmaster dying and
the bgwriter (or another process, perhaps) discovering this. Which means
that the bug/hardware problem/condition which killed the postmaster may
affect other live backends. Hmmm. Still, if we can minimise impact then
we're probably assisting. We could always add a GUC variable ;-).
Gavin
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
