(Yes, I know I'm not on the hackers list. Most interested parties should
get this directly anyway.)
>> Additionally the interface exposed by the JDBC driver lets the user
>> write arbitrary CopyData bytes to the server, so without parsing all of
>> that we don't know whether they've issued CopyData(EOF) or not.
>
> Okay, so you can't know with absolute certainty without parsing the
> data, but the usual case would be handled by holding onto the last-N
> bytes or so. Enough to fit the EOF and perhaps a little more for
> paranoia's sake.
>
> That's not to say that I'm missing the problem. When (not "if", "when")
> the user feeds data past a CopyData(EOF), it's going to get interesting.
This is the reason why the patch to the JDBC driver that I sent in is very
fragile. In the case where a user provides a binary copy with lots of data
after the EOF, the processCopyData method *will* get called after the
CommandComplete and ReadyForQuery messages have been received, even if we
try to delay processing of the ReadyForQuery message.
> [Thinking about the logic necessary to handle such a case and avoid
> network buffer deadlock...] I would think the least invasive way to
> handle it would be to set the CommandComplete and ReadyForQuery messages
> aside when they are received if CopyDone hasn't been sent, continue the
> COPY operation as usual until it is shutdown, send CopyDone and,
> finally, "reinstate" CommandComplete and RFQ as if they were just
> received..
Basically, yes. We need to introduce a little more state into the JDBC
driver. Currently, the driver is in one of two states:
1. In the middle of a copy.
2. Not in a copy.
These states are recorded in the lock system. We need to introduce a new
state, where the copy is still locked, but we know that the
CommandComplete and ReadyForQuery messages have been received. We can no
longer unlock the copy in processCopyData - we need to do that in endCopy
instead, after calling processCopyData to ensure that we wait for a valid
CommandComplete and ReadyForQuery message first.
Matthew
--
Terrorists evolve but security is intelligently designed? -- Jake von Slatt