On Wed, Nov 11, 2015 at 1:55 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Nov 4, 2015 at 2:18 AM, Robert Haas wrote: >> The second conclusion does not appear to be correct. parseInput() >> will call pqParseInput3() or pqParseInput2(), either of which will >> handle an error as if it were a notice - i.e. by printing it out. > > Right per pqGetErrorNotice3 when the connection is in PGASYNC_IDLE state. > >> Here's a patch based on that analysis, addressing just that one >> function, not any of the other changes talked about on this thread. >> Does this make sense? Would we want to back-patch it, and if so how >> far, or just adjust master? My gut is just master, but I don't know >> why this issue wouldn't also affect Hot Standby kills and maybe other >> kinds of connection termination situations, so maybe there's an >> argument for back-patching. On the third hand, failing to read the >> error message off of a just-terminated connection isn't exactly a >> crisis of the first order either. > > Looks sane to me. As the connection is in PGASYNC idle state when > crossing the path of pqHandleSendFailure() we would finish eating up > all the error messages received from server and print an internal > notice for the rest with "message type blah received from server while > idle. Based on the lack of complaints regarding libpq on this side, I > would just go for master, as for 9.5 is pretty late in this game to > put some dust on it before a potential backpatch.
OK, committed just to master then, plus the change which is the purpose of this thread. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
