Re: Dangling Client Backend Process - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Dangling Client Backend Process
Date
Msg-id CA+TgmoYjTfsjgTPJTpW-KZ8w4Oia1k460qVHr5WkCGuJvLvssw@mail.gmail.com
Whole thread Raw
In response to Re: Dangling Client Backend Process  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
List pgsql-hackers
On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> 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.

Yep.  +1 for changing this.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: a raft of parallelism-related bug fixes
Next
From: Stephen Frost
Date:
Subject: Re: SuperUser check in pg_stat_statements