From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, amit(dot)kapila16(at)gmail(dot)com, rajeev(dot)rastogi(at)huawei(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Dangling Client Backend Process |
Date: | 2015-10-17 20:52:03 |
Message-ID: | 20151017205203.GI3391@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund wrote:
> On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote:
> > If I recall correctly, he concerned about killing the backends
> > running transactions which could be saved. I have a sympathy with
> > the opinion.
>
> I still don't. Leaving backends alive after postmaster has died prevents
> the auto-restart mechanism to from working from there on. Which means
> that we'll potentially continue happily after another backend has
> PANICed and potentially corrupted shared memory. Which isn't all that
> unlikely if postmaster isn't around anymore.
I agree. When postmaster terminates without waiting for all backends to
go away, things are going horribly wrong -- either a DBA has done
something stupid, or the system is misbehaving. As Andres says, if
another backend dies at that point, things are even worse -- the dying
backend could have been holding a critical lwlock, for instance, or it
could have corrupted shared buffers on its way out. It is not sensible
to leave the rest of the backends in the system still trying to run just
because there is no one there to kill them.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2015-10-17 21:37:33 | Re: [HACKERS] max_worker_processes on the standby |
Previous Message | Robert Haas | 2015-10-17 19:23:11 | Re: Allow ssl_renegotiation_limit in PG 9.5 |