Re: Dangling Client Backend Process

On Tue, Oct 27, 2015 at 6:29 AM, Rajeev rastogi
<rajeev(dot)rastogi(at)huawei(dot)com> wrote:
> On 23 October 2015 01:58, Robert Haas [mailto:robertmhaas(at)gmail(dot)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 from user.
> 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 it comes 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 think there 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