Re: bgwriter never dies

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: bgwriter never dies
Date: 2004-02-25 04:21:57
Message-ID: Pine.LNX.4.58.0402251518060.7382@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-02-25 04:37:11 Re: [GENERAL] select statement against pg_stats returns
Previous Message Tom Lane 2004-02-25 04:15:26 Re: [HACKERS] select statement against pg_stats returns inconsistent data