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

On Tue, Oct 27, 2015 at 6:29 AM, Rajeev rastogi
<rajeev.rastogi@huawei.com> wrote:
> On 23 October 2015 01:58, Robert Haas [mailto:robertmhaas@gmail.com] Wrote:
>>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.
>
> Agree.
>
>>Here's a version with that removed and some changes to the comments.
>
> Thanks for changing.
>
>>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.
>
> Actually in this case client is not waiting for the response from the server rather it is waiting for new command
fromuser. 
> So even though server has sent the response to client, client is not able to receive.
> Once client receives the next command to execute, by the time connection has terminated from server side and hence
itcomes out with the above message (i.e. server closed the connection...) 
>
> Though I am also in favor of  providing some error message to client. But with the current infrastructure, I don’t
thinkthere is any way to pass this error message to client [This error has happened without involvement of the client
side].
>
> Comments?

Hmm.  ProcessInterrupts() signals some FATAL errors while the
connection is idle, and rumor has it that that works: the client
doesn't immediately read the FATAL error, but the next time it sends a
query, it tries to read from the connection and sees the FATAL error
at that time.  I wonder why that's not working here.

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