On 30 October 2015 20:33, Andres Freund Wrote: >On 2015-10-30 10:57:45 -0400, Tom Lane wrote: >> Andres Freund <and...@anarazel.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
dangle-v4.patch
Description: dangle-v4.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
