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

Hi postgres-hackers

While reviewing a doc patch[1] , I noticed that current explanation
about how postgres behaves when an OOM killer is invoked is not quite
correct.

Postgres doc [2] says:
> This indicates that the <filename>postgres</filename> process
> has been terminated due to memory pressure.
> Although existing database connections will continue to function
> normally, no new connections will be accepted. To recover,
> <productname>PostgreSQL</productname> will need to be restarted.

But I believe all postgres processes will be terminated in this case.
When a backend process is terminated by an OOM killer, the whole
postgres will be restarted or stop depending on restart_after_crash
setting. In a special case where postmaster is killed, each backend
proccesses will also eventually be terminated. The backend process will
be stopped when it notices postmaster is terminated. In this case, the
postgres will just stop and a user needs to restart it. I tested above
two cases and checked the relevant codes.

The statement was very old and committed at 02cd2b96acdb in 2003. I
assume it was correct at the time but I believe it's not as of now
though I haven't checked.

Could you check attached patch?
The original document mentions to postmaster explicitly. So, in my patch
I explain how postmaster and other processes work when OOM killer is
invoked.

[1]
https://www.postgresql.org/message-id/flat/CABH8dKwkp1_TzR7nxfvSpRSLD1b33xw7N_VLMLy3MiaEjAEPNw%40mail.gmail.com

[2]
https://www.postgresql.org/docs/devel/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

Thank you,
Takeshi Ideriha