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

Hi Manu

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

Thank you.

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

Thank you for the suggestion. I agree that mapping the kernel message to
the server log would be useful for readers.
But I'd like to focus on correcting the wrong sentence for now.
Current "Linux Memory Overcommit" section is somewhat long and these
logs are easy to understand so I'd like to make this out of scope.

Regards,
Takeshi Ideriha