From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Aleksey Tsalolikhin" <atsaloli(dot)tech(at)gmail(dot)com>, "John R Pierce" <pierce(at)hogranch(dot)com>, pgsql-general(at)postgresql(dot)org, "Craig Ringer" <ringerc(at)ringerc(dot)id(dot)au> |
Subject: | Re: postgres process got stuck in "notify interrupt waiting" status |
Date: | 2012-09-05 15:33:45 |
Message-ID: | 17560.1346859225@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Aleksey Tsalolikhin <atsaloli(dot)tech(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | jam3 | 2012-09-05 15:40:41 | Where is the char and varchar length in pg_catalog for function input variables |
Previous Message | Kevin Grittner | 2012-09-05 15:29:45 | Re: postgres process got stuck in "notify interrupt waiting" status |