Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit f208fb4

Browse files
committed
Clean up error cases in psql's COPY TO STDOUT/FROM STDIN code.
Adjust handleCopyOut() to stop trying to write data once it's failed one time. For typical cases such as out-of-disk-space or broken-pipe, additional attempts aren't going to do anything but waste time, and in any case clean truncation of the output seems like a better behavior than randomly dropping blocks in the middle. Also remove dubious (and misleadingly documented) attempt to force our way out of COPY_OUT state if libpq didn't do that. If we did have a situation like that, it'd be a bug in libpq and would be better fixed there, IMO. We can hope that commit fa4440f took care of any such problems, anyway. Also fix longstanding bug in handleCopyIn(): PQputCopyEnd() only supports a non-null errormsg parameter in protocol version 3, and will actively fail if one is passed in version 2. This would've made our attempts to get out of COPY_IN state after a failure into infinite loops when talking to pre-7.4 servers. Back-patch the COPY_OUT state change business back to 9.2 where it was introduced, and the other two fixes into all supported branches.
1 parent fb47de2 commit f208fb4

File tree

1 file changed

+37
-38
lines changed

1 file changed

+37
-38
lines changed

src/bin/psql/copy.c

Lines changed: 37 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -447,15 +447,15 @@ handleCopyOut(PGconn *conn, FILE *copystream)
447447
ret = PQgetCopyData(conn, &buf, 0);
448448

449449
if (ret < 0)
450-
break; /* done or error */
450+
break; /* done or server/connection error */
451451

452452
if (buf)
453453
{
454-
if (fwrite(buf, 1, ret, copystream) != ret)
454+
if (OK && fwrite(buf, 1, ret, copystream) != ret)
455455
{
456-
if (OK) /* complain only once, keep reading data */
457-
psql_error("could not write COPY data: %s\n",
458-
strerror(errno));
456+
psql_error("could not write COPY data: %s\n",
457+
strerror(errno));
458+
/* complain only once, keep reading data from server */
459459
OK = false;
460460
}
461461
PQfreemem(buf);
@@ -476,29 +476,18 @@ handleCopyOut(PGconn *conn, FILE *copystream)
476476
}
477477

478478
/*
479-
* Check command status and return to normal libpq state. After a
480-
* client-side error, the server will remain ready to deliver data. The
481-
* cleanest thing is to fully drain and discard that data. If the
482-
* client-side error happened early in a large file, this takes a long
483-
* time. Instead, take advantage of the fact that PQexec() will silently
484-
* end any ongoing PGRES_COPY_OUT state. This does cause us to lose the
485-
* results of any commands following the COPY in a single command string.
486-
* It also only works for protocol version 3. XXX should we clean up
487-
* using the slow way when the connection is using protocol version 2?
479+
* Check command status and return to normal libpq state.
488480
*
489-
* We must not ever return with the status still PGRES_COPY_OUT. Our
490-
* caller is unable to distinguish that situation from reaching the next
491-
* COPY in a command string that happened to contain two consecutive COPY
492-
* TO STDOUT commands. We trust that no condition can make PQexec() fail
493-
* indefinitely while retaining status PGRES_COPY_OUT.
481+
* If for some reason libpq is still reporting PGRES_COPY_OUT state, we
482+
* would like to forcibly exit that state, since our caller would be
483+
* unable to distinguish that situation from reaching the next COPY in a
484+
* command string that happened to contain two consecutive COPY TO STDOUT
485+
* commands. However, libpq provides no API for doing that, and in
486+
* principle it's a libpq bug anyway if PQgetCopyData() returns -1 or -2
487+
* but hasn't exited COPY_OUT state internally. So we ignore the
488+
* possibility here.
494489
*/
495-
while (res = PQgetResult(conn), PQresultStatus(res) == PGRES_COPY_OUT)
496-
{
497-
OK = false;
498-
PQclear(res);
499-
500-
PQexec(conn, "-- clear PGRES_COPY_OUT state");
501-
}
490+
res = PQgetResult(conn);
502491
if (PQresultStatus(res) != PGRES_COMMAND_OK)
503492
{
504493
psql_error("%s", PQerrorMessage(conn));
@@ -541,7 +530,9 @@ handleCopyIn(PGconn *conn, FILE *copystream, bool isbinary)
541530
/* got here with longjmp */
542531

543532
/* Terminate data transfer */
544-
PQputCopyEnd(conn, _("canceled by user"));
533+
PQputCopyEnd(conn,
534+
(PQprotocolVersion(conn) < 3) ? NULL :
535+
_("canceled by user"));
545536

546537
OK = false;
547538
goto copyin_cleanup;
@@ -662,29 +653,37 @@ handleCopyIn(PGconn *conn, FILE *copystream, bool isbinary)
662653
if (ferror(copystream))
663654
OK = false;
664655

665-
/* Terminate data transfer */
656+
/*
657+
* Terminate data transfer. We can't send an error message if we're using
658+
* protocol version 2.
659+
*/
666660
if (PQputCopyEnd(conn,
667-
OK ? NULL : _("aborted because of read failure")) <= 0)
661+
(OK || PQprotocolVersion(conn) < 3) ? NULL :
662+
_("aborted because of read failure")) <= 0)
668663
OK = false;
669664

670665
copyin_cleanup:
671666

672667
/*
673-
* Check command status and return to normal libpq state
668+
* Check command status and return to normal libpq state.
674669
*
675-
* We must not ever return with the status still PGRES_COPY_IN. Our
676-
* caller is unable to distinguish that situation from reaching the next
677-
* COPY in a command string that happened to contain two consecutive COPY
678-
* FROM STDIN commands. XXX if something makes PQputCopyEnd() fail
679-
* indefinitely while retaining status PGRES_COPY_IN, we get an infinite
680-
* loop. This is more realistic than handleCopyOut()'s counterpart risk.
670+
* We do not want to return with the status still PGRES_COPY_IN: our
671+
* caller would be unable to distinguish that situation from reaching the
672+
* next COPY in a command string that happened to contain two consecutive
673+
* COPY FROM STDIN commands. We keep trying PQputCopyEnd() in the hope
674+
* it'll work eventually. (What's actually likely to happen is that in
675+
* attempting to flush the data, libpq will eventually realize that the
676+
* connection is lost. But that's fine; it will get us out of COPY_IN
677+
* state, which is what we need.)
681678
*/
682679
while (res = PQgetResult(conn), PQresultStatus(res) == PGRES_COPY_IN)
683680
{
684681
OK = false;
685682
PQclear(res);
686-
687-
PQputCopyEnd(pset.db, _("trying to exit copy mode"));
683+
/* We can't send an error message if we're using protocol version 2 */
684+
PQputCopyEnd(conn,
685+
(PQprotocolVersion(conn) < 3) ? NULL :
686+
_("trying to exit copy mode"));
688687
}
689688
if (PQresultStatus(res) != PGRES_COMMAND_OK)
690689
{

0 commit comments

Comments
 (0)