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

From Amit Kapila
Subject Re: Dangling Client Backend Process
Date
Msg-id CAA4eK1KdnneLFDetB9L24jGkb7VLEd9RVYsyEB5a18HPAY9SSw@mail.gmail.com
Whole thread Raw
In response to Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Responses Re: Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
List pgsql-hackers
On Sat, Oct 10, 2015 at 3:42 PM, Rajeev rastogi <rajeev.rastogi@huawei.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

pgsql-hackers by date:

Previous
From: Amir Rohan
Date:
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Next
From: Michael Paquier
Date:
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.