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