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
