Re: Dangling Client Backend Process

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dangling Client Backend Process
Date: 2015-11-03 05:37:41
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7715996F3C8@szxeml521-mbs.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30 October 2015 20:33, Andres Freund Wrote:
>On 2015-10-30 10:57:45 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>> > adding a parseInput(conn) into the loop yields the expected
>> > FATAL: 57P01: terminating connection due to unexpected postmaster
>> > exit Is there really any reason not to do that?
>>
>> Might work, but it probably needs some study:
>
>Yea, definitely. I was just at pgconf.eu's keynote catching up on a talk.
>No fully thought through proposal's to be expected ;)
>
>> (a) is it safe
>
>I don't immediately see why not.
>
>> (b) is this the right place / are there other places
>
>I think it's ok for the send failure case, in a quick lookthrough I
>didn't find anything else for writes - I'm not entirely sure all read
>cases are handled tho, but it seems less likely to be mishandles.

I also did some analysis as Andres suggested and observed that since the error message is already sent by backend to frontend,
so error message is available on connection channel just that is was not received/processed by frontend.
Also pqHandleSendFailure was checking the available data if any but it was ignored to process.

So as Andres suggested above, if we add parseInput to receiver and parse the available message on connection channel, we could display appropriate error.

IMHO above proposed place to add parseInput seems to be right, as already this function takes of handling " NOTICE message that the backend might have sent just before it died "

Attached is the patch with this change.

Comments?

Thanks and Regards,
Kumar Rajeev Rastogi

Attachment Content-Type Size
dangle-v4.patch application/octet-stream 3.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-11-03 06:19:43 Re: NOTIFY in Background Worker
Previous Message Tom Lane 2015-11-03 03:40:25 Re: ALTER SYSTEM vs symlink