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

Hi Takeshi,

> Both of your points make sense. I added them in v2 patch.

v2 reads correctly to me -- both the restart_after_crash=off case and the
pointer to the postmaster oom_score_adj are now covered, and the wording
matches what I reproduced.

One thing that might further help the reader, if it is in scope: the
section shows the kernel message but not what PostgreSQL itself logs, and
since every process is named "postgres" the reader cannot tell from
"Killed process 12345 (postgres)" alone which of your two cases applies.
The server log is what separates them. When a child is killed, the
postmaster logs (with restart_after_crash on):

LOG: client backend (PID 769432) was terminated by signal 9: Killed
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system is ready to accept connections

When the postmaster itself is killed there is no such reinitialization
sequence -- the log simply ends and the backends exit as they notice it
is gone. That mapping also answers the "where to look" the kernel-message
note leaves open: the kernel log for the OOM line, the server log for the
effect. Might be more than this fix intends, so feel free to leave it for
a follow-up.

Regards,
Manu