Re: Dangling Client Backend Process

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Dangling Client Backend Process
Дата
Msg-id CA+TgmoYqNcfSih7gO5iqRYvfKKSrKabS=omSB7WBKi2FO8UvTA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Ответы Re: Dangling Client Backend Process  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
Список pgsql-hackers
On Tue, Oct 20, 2015 at 11:42 PM, Rajeev rastogi
<rajeev.rastogi@huawei.com> wrote:
> Agreed. Attached is the patch with changes.

Well, I'm not buying this extra PostmasterIsAlive() call on every pass
through the main loop.  That seems more expensive than we can really
justify. Checking this when we're already calling WaitLatchOrSocket is
basically free, but the other part is not.

Here's a version with that removed and some changes to the comments.
I still don't think this is quite working right, though, because
here's what happened when I killed the postmaster:

rhaas=# select 1;
 ?column?
----------
        1
(1 row)

rhaas=# \watch
Watch every 2s    Thu Oct 22 16:24:10 2015

 ?column?
----------
        1
(1 row)

Watch every 2s    Thu Oct 22 16:24:12 2015

 ?column?
----------
        1
(1 row)

Watch every 2s    Thu Oct 22 16:24:14 2015

 ?column?
----------
        1
(1 row)

Watch every 2s    Thu Oct 22 16:24:16 2015

 ?column?
----------
        1
(1 row)

server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Note that the error message doesn't actually show up on the client (it
did show up in the log).  I guess that may be inevitable if we're
blocked in secure_write(), but if we're in secure_read() maybe it
should work?  I haven't investigated why it doesn't.

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

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] SQL function to report log message
Следующее
От: Tom Lane
Дата:
Сообщение: Re: clearing opfuncid vs. parallel query