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

From Robert Haas
Subject Re: Dangling Client Backend Process
Date
Msg-id CA+TgmoYqNcfSih7gO5iqRYvfKKSrKabS=omSB7WBKi2FO8UvTA@mail.gmail.com
Whole thread Raw
In response to Re: 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 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] SQL function to report log message
Next
From: Tom Lane
Date:
Subject: Re: clearing opfuncid vs. parallel query