"Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes: > Aleksey Tsalolikhin <atsaloli.tech@xxxxxxxxx> wrote: >> Why will it kill all your other sessions too? Isn't there a >> separate backend process for each session? > When stopped that abruptly, the process has no chance to clean up > its pending state in shared memory. A fresh copy of shared memory > is needed, so it is necessary to effectively do an immediate restart > on the whole PostgreSQL instance. Right. On seeing one child die unexpectedly, the postmaster forcibly SIGQUITs all its other children and initiates a crash recovery sequence. The reason for this is exactly that we can't trust the contents of shared memory anymore. An example is that the dying backend may have held some critical lock, which there is no way to release, so that every other session will shortly be stuck anyway. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
