Re: How to shoot yourself in the foot: kill -9 postmaster

Tom Lane wrote:
> Yeah, but only a partial crash. If the admin finishes the job by
> killing the backends too, we're fine. Postmaster down, backends alive
> is not a scenario we're currently prepared for. We need a way to plug
> that gap.

Postmaster can easily enough find out if zombie backends are 'out there'
during startup, right? What can postmaster _do_ about it, though? It
won't necessarily be able to kill them -- but it also can't control
them. If it _can_ kill them, should it try?

After all, if those zombies are out there on this PGDATA there's going
to be big trouble if we even try to start. If we can't kill the zombies
(that might still be doing something useful with their clients) from our
starting postmaster, how can we possibly start up underneath running
backends?

Should the backend look for the presence of its parent postmaster
periodically and gracefully come down if postmaster goes away without
the proper handshake? A watchdog semaphore (or shared memory flag) that
the backend resets and then checks periodically for it being set by its
parent postmaster?

Should a set of backends detect a new postmaster coming up and try to
'sync up' with that postmaster, like the baroque GEMM handshake dance
performed by 386 memory managers when Windows needs to start its own
VMM?

Or should we spend that much time protecting Barney Fife's from their
own single bullet? :-)

Just a nor-easter of a brainstorm....
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11