diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-11-12 13:03:52 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-11-12 13:03:52 -0500 |
commit | c405918858c09d4264ffc5a3c73d57dc3efb0213 (patch) | |
tree | 914396859003c25787d0c412acd580ec8db5be36 /src/interfaces/libpq/fe-exec.c | |
parent | c3e7c24a1d60dc6ad56e2a0723399f1570c54224 (diff) | |
download | postgresql-c405918858c09d4264ffc5a3c73d57dc3efb0213.tar.gz postgresql-c405918858c09d4264ffc5a3c73d57dc3efb0213.zip |
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
In commit 210eb9b743c0645d I centralized libpq's logic for closing down
the backend communication socket, and made the new pqDropConnection
routine always reset the I/O buffers to empty. Many of the call sites
previously had not had such code, and while that amounted to an oversight
in some cases, there was one place where it was intentional and necessary
*not* to flush the input buffer: pqReadData should never cause that to
happen, since we probably still want to process whatever data we read.
This is the true cause of the problem Robert was attempting to fix in
c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final
ERROR message before reporting "server closed the connection unexpectedly".
But that only accidentally fixed it, by invoking parseInput before the
input buffer got flushed; and very likely there are timing scenarios
where we'd still lose the message before processing it.
To fix, pass a flag to pqDropConnection to tell it whether to flush the
input buffer or not. On review I think flushing is actually correct for
every other call site.
Back-patch to 9.3 where the problem was introduced. In HEAD, also improve
the comments added by c3e7c24a1d60dc6a.
Diffstat (limited to 'src/interfaces/libpq/fe-exec.c')
-rw-r--r-- | src/interfaces/libpq/fe-exec.c | 17 |
1 files changed, 10 insertions, 7 deletions
diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c index 07c43355211..f71df324bd5 100644 --- a/src/interfaces/libpq/fe-exec.c +++ b/src/interfaces/libpq/fe-exec.c @@ -1553,8 +1553,10 @@ sendFailed: /* * pqHandleSendFailure: try to clean up after failure to send command. * - * Primarily, what we want to accomplish here is to process any messages that - * the backend might have sent just before it died. + * Primarily, what we want to accomplish here is to process any ERROR or + * NOTICE messages that the backend might have sent just before it died. + * Since we're in IDLE state, all such messages will get sent to the notice + * processor. * * NOTE: this routine should only be called in PGASYNC_IDLE state. */ @@ -1562,16 +1564,17 @@ void pqHandleSendFailure(PGconn *conn) { /* - * Accept and parse any available input data. Note that if pqReadData - * decides the backend has closed the channel, it will close our side of - * the socket --- that's just what we want here. + * Accept and parse any available input data, ignoring I/O errors. Note + * that if pqReadData decides the backend has closed the channel, it will + * close our side of the socket --- that's just what we want here. */ while (pqReadData(conn) > 0) parseInput(conn); /* - * Make one attempt to parse available input messages even if we read no - * data. + * Be sure to parse available input messages even if we read no data. + * (Note: calling parseInput within the above loop isn't really necessary, + * but it prevents buffer bloat if there's a lot of data available.) */ parseInput(conn); } |