Re: postgres process got stuck in "notify interrupt waiting" status

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

In response to

Responses

Browse pgsql-general by date

  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