On Sat, 24 Jul 2010, James William Pye wrote:
> On Jul 23, 2010, at 7:11 AM, Tom Lane wrote:
>> I can't help thinking that the JDBC driver must be being overly cute
>> if this breaks it ...
>
> I was wondering the same thing when I first saw Kris' message. However,
> iff I understand what JDBC is trying to achieve, I don't think I would
> call it "overly".
>
> Is this a problem because JDBC is trying to detect failures as early as
> possible during a COPY IN? Or, is it just JDBC's normal MO to always be
> reading?
The JDBC driver reads server messages for multiple reasons. One of them
is indeed to do early failure detection. Another is to pickup
NoticeResponse messages to avoid a network buffer deadlock. If someone
puts a trigger on the table you're copying data into that does RAISE
NOTICE 'received row X' for each row, to avoid a full network buffer
deadlock, the client must regularly read from the backend. So as we are
reading along, supposing that we're still mid-copy, we get a command
complete message. So this is possible to work around driver side by
peeking into the network stream and delaying processing of the end of copy
until the driver agrees that the copy is done, but I still maintain that
this is a server bug. It is not OK for the server to assume that the
client is done and move on, the client must tell the server what it wants
done.
Kris Jurka
