While looking at the pending patch to make psql report a line count
after COPY, I came across this business in handleCopyOut():
* Check command status and return to normal libpq state. After a
* client-side error, the server will remain ready to deliver data. The
* cleanest thing is to fully drain and discard that data. If the
* client-side error happened early in a large file, this takes a long
* time. Instead, take advantage of the fact that PQexec() will silently
* end any ongoing PGRES_COPY_OUT state. This does cause us to lose the
* results of any commands following the COPY in a single command string.
* It also only works for protocol version 3. XXX should we clean up
* using the slow way when the connection is using protocol version 2?
which git blames on commit 08146775 (committed by Alvaro on behalf of
Noah).
This does not make me happy. In the first place, we have not dropped
support for protocol version 2. In the second place, I fail to see
what the advantage is of kluging things like this. The main costs of
draining the remaining COPY data are the server-side work of generating
the data and the network transmission costs, neither of which will go
away with this technique. So I'm thinking we should revert this kluge
and just drain the data straightforwardly, which would also eliminate
the mentioned edge-case misbehavior when there were more commands in
the query string.
Is there a reason I'm overlooking not to do this?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
