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

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> Tom Lane wrote:
>> 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?

If you think it's easy enough, enlighten the rest of us ;-). Be sure
your solution only finds leftover backends from the previous instance of
the same postmaster, else it will prevent running multiple postmasters
on one system.

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

I think refusal to start is sufficient. They should go away by
themselves as their clients disconnect, and forcing the issue doesn't
seem like it will improve matters. The admin can kill them (hopefully
with just a SIGTERM ;-)) if he wants to move things along ... but I'd
not like to see a newly-starting postmaster do that automatically.

> Should the backend look for the presence of its parent postmaster
> periodically and gracefully come down if postmaster goes away without
> the proper handshake?

Unless we checked just before every disk write, this wouldn't represent
a safe failure mode. The onus has to be on the newly-starting
postmaster, I think, not on the old backends.

> Should a set of backends detect a new postmaster coming up and try to
> 'sync up' with that postmaster,

Nice try ;-). How will you persuade the kernel that these processes are
now children of the new postmaster?

regards, tom lane