Re: Dangling Client Backend Process

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Dangling Client Backend Process
Дата
Msg-id CAA4eK1KdnneLFDetB9L24jGkb7VLEd9RVYsyEB5a18HPAY9SSw@mail.gmail.com
обсуждение исходный текст
Ответ на Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Ответы Re: Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Список 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 по дате отправления:

Предыдущее
От: Amir Rohan
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.