"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Aleksey Tsalolikhin <atsaloli.tech@gmail.com> 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