On Tue, 20 Jul 2010, Matthew Wakeling wrote:
> On Tue, 20 Jul 2010, Matthew Wakeling wrote:
>> So, should the unlocking happen elsewhere, or should endCopy not require a
>> lock?
>
> Or a third option. We should delay the processing of the "Z" (Ready for
> query) message until after the endCopy has been called.
>
> I have still not been able to create a test that provokes this bug. I do not
> understand under what conditions the server will do this, but sometimes it
> will respond with a "C" and a "Z" before the endCopy message has actually
> been sent to it. Maybe it is keying off the "-1" (no further rows) part of
> the binary copy. In any case, I am including a patch here which seems to fix
> the driver for my application. When the driver receives a "C" message
> (command finished), and block is set to false, then we can assume that a
> little later on we will call processCopyResults again very soon with block
> set to true. Instead of setting block to true, finish processing of messages
> in order to delay seeing the "Z" message until after the endCopy method has
> been called.
>
> The patch also contains a simple test for binary copy in, although it does
> not exercise this bug.
I've applied a patch to CVS to implement a variant of this that is more
selective of what it ignores. It peeks into the protocol stream and
ignores all CommandComplete messages while we aren't blocking (which
means that the driver thinks it isn't done yet).
Kris Jurka