summaryrefslogtreecommitdiff
path: root/HISTORY
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2014-02-12 17:50:07 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2014-02-12 17:50:57 -0500
commitfa4440f51628d692f077d54b8313aea31af087ea (patch)
treeea38254ecf8a90690c76236ee9137a73ccc70165 /HISTORY
parent993c3961a4166a766c9b0a67701e9c82432550cc (diff)
downloadpostgresql-fa4440f51628d692f077d54b8313aea31af087ea.tar.gz
Improve libpq's error recovery for connection loss during COPY.
In pqSendSome, if the connection is already closed at entry, discard any queued output data before returning. There is no possibility of ever sending the data, and anyway this corresponds to what we'd do if we'd detected a hard error while trying to send(). This avoids possible indefinite bloat of the output buffer if the application keeps trying to send data (or even just keeps trying to do PQputCopyEnd, as psql indeed will). Because PQputCopyEnd won't transition out of PGASYNC_COPY_IN state until it's successfully queued the COPY END message, and pqPutMsgEnd doesn't distinguish a queuing failure from a pqSendSome failure, this omission allowed an infinite loop in psql if the connection closure occurred when we had at least 8K queued to send. It might be worth refactoring so that we can make that distinction, but for the moment the other changes made here seem to offer adequate defenses. To guard against other variants of this scenario, do not allow PQgetResult to return a PGRES_COPY_XXX result if the connection is already known dead. Make sure it returns PGRES_FATAL_ERROR instead. Per report from Stephen Frost. Back-patch to all active branches.
Diffstat (limited to 'HISTORY')
0 files changed, 0 insertions, 0 deletions