Re: kill -KILL: What happens? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: kill -KILL: What happens?
Date
Msg-id 21877.1294946166@sss.pgh.pa.us
Whole thread Raw
In response to Re: kill -KILL: What happens?  (Florian Pflug <fgp@phlo.org>)
Responses Re: kill -KILL: What happens?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Florian Pflug <fgp@phlo.org> writes:
> Couldn't normal backends call PostmasterIsAlive and exit if not, just
> like the startup process, the stats collector, autovacuum, bgwriter,
> walwriter, walreceiver, walsender and the wal archiver already do?

> I assumed they do, but now that I grepped the code it seems they don't.

That's intentional: they keep going until the user closes the session or
someone sends them a signal to do otherwise.  The other various
background processes have to watch PostmasterIsAlive because there is no
session to close.

Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
It sucks because you don't get a signal on parent death.  With the
arrival of the latch code, having to check for PostmasterIsAlive
frequently is the only reason for an idle background process to consume
CPU at all.

Another problem with the scheme is that it only works as long as the
background process is providing a *non critical* service.  Eventually we
are probably going to need some way for bgwriter/walwriter to stay alive
long enough to service orphaned backends, rather than disappearing
instantly if the postmaster goes away.
        regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: kill -KILL: What happens?
Next
From: Tom Lane
Date:
Subject: Re: kill -KILL: What happens?