Re: Fix doc: explanation of how postgres works when OOM killer is invoked

Hi Takeshi,

> But I believe all postgres processes will be terminated in this case.
> [...] The backend process will be stopped when it notices postmaster
> is terminated.

I looked into this as well, and the patch matches what I see. In the
reaper (postmaster.c) any child that exits abnormally goes through
HandleChildCrash, so there is no special case for an OOM SIGKILL. I
reproduced it: killing a client backend, the checkpointer, the walwriter,
the archiver, or the autovacuum launcher each ends with the postmaster
logging "all server processes terminated; reinitializing" (with
restart_after_crash on), i.e. every connection is gone. Killing the
postmaster instead leaves the backends up until they notice its death and
exit, and new connections are refused until a manual restart. So the old
"existing database connections will continue to function normally" no
longer holds for the usual case.

Two small things:

- With restart_after_crash off, the server does not stay down passively:
it logs 'shutting down because "restart_after_crash" is off' and shuts
the whole cluster down, so a manual restart is needed. The patch gives
the "on" case; it might be worth saying what "off" does too.

- A little further down, this same section recommends protecting the
postmaster with a low oom_score_adj so the OOM killer picks a child.
With that in place the victim is a backend -- your "another server
process" case -- while "the postmaster is terminated" is mostly what
happens without that protection. Relating the two might help the
reader, though it may be more than this fix intends.

The wording reads well to me otherwise.

Regards,
Manu