Victor Yegorov <vyegorov@gmail.com> writes:
> ср, 28 окт. 2020 г. в 19:44, Alexander Kukushkin <cyberdemn@gmail.com>:
>> I know, nobody in their mind should do that, but, if the postmaster
>> process is killed with SIGKILL signal, most backend processes
>> correctly notice the fact of the postmaster process absence and exit.
>> There is one exception though, when there are autovacuum worker
>> processes they are continuing to run until eventually finish and exit.
> Do you get the same behaviour also on master?
> As there was some work in this area for 14, see
> https://git.postgresql.org/pg/commitdiff/44fc6e259b
That was about SIGQUIT response, which isn't really related to this
scenario. But I do not think Alexander has accurately characterized
the situation. *No* server processes will react instantly to postmaster
death. Typically they'll only detect it while waiting for some other
condition, such as client input, or in some cases while iterating their
outermost loop. So if they're busy with calculations they might not
notice for a long time. I don't think autovacuum is any worse than
a busy client backend on this score.
It's hard to do better than that, because on most platforms there's
no way to get a signal on parent-process death, so the only way to
notice would be to poll the postmaster-death pipe constantly; which
would be hugely expensive in comparison to the value.
On the whole I'm skeptical that this is a useful consideration to
expend effort on. You shouldn't be killing the postmaster that way.
If you do, you'll soon learn not to, for plenty of reasons besides
this one.
regards, tom lane
