| commit | e6d4fe6743125ba7099534c6a72bc77c8247a4d0 | |
| author | Tom Lane <tgl@sss.pgh.pa.us> | |
| Sat, 18 Sep 2010 20:10:15 +0000 (18 20:10 +0000) | ||
| committer | Tom Lane <tgl@sss.pgh.pa.us> | |
| Sat, 18 Sep 2010 20:10:15 +0000 (18 20:10 +0000) | ||
| tree | 01ee8290df0a78a02dd5284d86eb4763ecb3b00a | treesnapshot (tar.gz zip) |
| parent | 6405ae6db9e9cfc4b43ee63764f065311266e823 | commitdiff |
Make sure we wait for protocol-level EOF when ending binary COPY IN.
The previous coding just terminated the COPY immediately after seeing
the EOF marker (-1 where a row field count is expected). The expected
CopyDone or CopyFail message just got thrown away later, since we weren't
in COPY mode anymore. This behavior complicated matters for the JDBC
driver, and arguably was the wrong thing in any case since a CopyFail
message after the marker wouldn't be honored.
Note that there is a behavioral change here: extra data after the EOF
marker was silently ignored before, but now it will cause an error.
Hence not back-patching, although this is arguably a bug.
Per report and patch by Kris Jurka.
The previous coding just terminated the COPY immediately after seeing
the EOF marker (-1 where a row field count is expected). The expected
CopyDone or CopyFail message just got thrown away later, since we weren't
in COPY mode anymore. This behavior complicated matters for the JDBC
driver, and arguably was the wrong thing in any case since a CopyFail
message after the marker wouldn't be honored.
Note that there is a behavioral change here: extra data after the EOF
marker was silently ignored before, but now it will cause an error.
Hence not back-patching, although this is arguably a bug.
Per report and patch by Kris Jurka.
| src/backend/commands/copy.c | diffblobblamehistory |