Re: Dangling Client Backend Process

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Dangling Client Backend Process
Дата
Msg-id CAA4eK1Kbkq0NcXt29Tk2cWXPGrOP24k4L42kPHcfAocV09UfZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Список pgsql-hackers
On Fri, Oct 16, 2015 at 3:34 PM, Rajeev rastogi <rajeev.rastogi@huawei.com> wrote:

Yes it will be really helpful to know the earlier reason for "not making backend exit on postmaster death".
Please let me know if there is any thread, which I can refer to find the same.

IMHO there could be below major issues, if we don't kill client backend process on postmaster death:
1. Postmaster cannot be re-started again as pointed by Kyotaro and Andres Also.
2. If from existing client session, we try to do some operation which has dependency with backend process, then that operation will either fail or may lead to undefined behavior sometime.
3. Also unintentionally all operation done by application will not be checkpointed and also will not be flushed by bgworker.
4. Replicating of WAL to standby will be stopped and if synchronous standby is configured then command from master will be hanged.


What exactly we want to do as part of this proposal?  As far as I
can see, we have below two options on postmaster death:

a. Exit all the active backends in whichever state they are.
b. Exit backend/s after they finish there current work and are
waiting for new command.

I think what we are discussing here is option-b.


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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan