On Thu, 22 Jul 2010, Maciek Sakrejda wrote:
>> I can try and reproduce that. However, I will point out that the patch I
>> sent to the list which delays the reading of the Z does fix the problem.
>
> Sorry, I missed that. I'm not crazy about the logic (if I'm following
> it correctly), but it seems relatively sound (and has the benefit of
> being minimally invasive).
No, the logic sucks, as it is full of possible failure modes. What if you
for some reason call processCopyResults() again, after deciding to delay
after seeing the C, but before calling endCopy()? It'd see the Z and fail.
Anyway, I have just tried to get it to fail using the method you
suggested, and failed. For some reason, it seems that the server only
responds early under some circumstances that I can't work out. The test
case I have here doesn't do it. It does seem to be data dependent.
For reference, I edited CopyManager, and put a ten second sleep just
before endCopy(). I edited QueryExecutorImpl and put a flush after each
pgStream.send(data), and I put a processCopyResults() right at the
beginning of endCopy. This should provoke an error if the server does the
wrong thing.
I'll try using this in my application, and see what happens. Will get back
to you.
Matthew
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. - Kernighan