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

From Rajeev rastogi
Subject Re: Dangling Client Backend Process
Date
Msg-id BF2827DCCE55594C8D7A8F7FFD3AB7715996C01F@szxeml521-mbs.china.huawei.com
Whole thread Raw
In response to Re: Dangling Client Backend Process  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Dangling Client Backend Process
List pgsql-hackers
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 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
comesout 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?

Thanks and Regards,
Kumar Rajeev Rastogi

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: questions about PG update performance
Next
From: Kouhei Kaigai
Date:
Subject: Re: [DESIGN] ParallelAppend