Re: Dangling Client Backend Process

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dangling Client Backend Process
Date: 2015-10-10 12:45:03
Message-ID: CAA4eK1KdnneLFDetB9L24jGkb7VLEd9RVYsyEB5a18HPAY9SSw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 10, 2015 at 3:42 PM, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
wrote:

> I observed one strange behavior today that if postmaster process gets
> crashed/killed, then it kill all background processes but not the client
> backend process.
>
> Moreover it is also allowed to execute query on the connected client
> session without any other background process.
>
> But If I try to execute some command (like checkpoint) from the client
> session which requires any background task to perform, it fails because it
> cannot find the corresponding background process (like checkpoint process).
>
>
>
> I am not sure if this is already known behavior but I found it to be
> little awkward. This may lead to some unknown behavior in user application.
>
>
>

This is a known behaviour and there was some discussion on this
topic [1] previously as well. I think that thread didn't reach to
conclusion,
but there were couple of other reasons discussed in that thread as well to
have the behaviour as you are proposing here.

> Currently All background process keeps checking if Postmaster is Alive
> while they wait for any event but for client backend process there is no
> such mechanism.
>
>
>
> One way to handle this issue will be to check whether postmaster is alive
> after every command read but it will add extra cost for each query
> execution.
>
>
I don't think that is a good idea as if there is no command execution
it will still stay as it is and doing such operations on each command
doesn't sound to be good idea even though overhead might not be
big. There are some other ideas discussed in that thread [2] to achieve
this behaviour, but I think we need to find a portable way to achieve it.

[1] - http://www.postgresql.org/message-id/26217.1371851061@sss.pgh.pa.us
[2] -
http://www.postgresql.org/message-id/20130622174922.GD1254@alap2.anarazel.de

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-10-10 13:32:07 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Previous Message Amir Rohan 2015-10-10 12:04:40 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.