Re: bgwriter never dies - Mailing list pgsql-hackers

Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> Tom Lane wrote:
>>> Maybe there should be a provision similar to the stats collector's
>>> check-for-read-ready-from-a-pipe?
> 
>> 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.
> 
> That's not "worse", really.  Any backends that are still alive are
> committing real live transactions --- they're telling their clients
> they committed, so we'd better commit.  I don't mind if performance gets
> worse or if we lose pg_stats statistics, but we'd better not adopt the
> attitude that transaction correctness no longer matters after a
> postmaster crash.
> 
> So one thing we ought to think about here is whether system correctness
> depends on the bgwriter continuing to run until the last backend is
> gone.  AFAICS that is not true now --- the bgwriter just improves
> performance --- but we'd better decide what our plan for the future is.
> 
>> 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?
> 
> We do not; I'm not sure the notion of a process group is even portable,
> and I am pretty sure that the API to control process grouping isn't.
> 
>> 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.
> 
> 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.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #