Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
The COM_MULTI idea did not fly well with connectors.
I'm not aware of plans to use it on connectors, or to develop anything further with it.
Indeed, everything it can do, is possible without changing the protocol, using pipelining techique that JDBC is already successfully deploying. Or the old good JDBC batching,
The possible (and frankly, tiny) advantage of optimiting TCP traffic, in a manner similar to TCP_DELAY, can already be done using tcp_nodelay=0 setting.
Yet the server code is essentially dead compiled, and deployed. It insignificantly slows down the execution of dispatch_command. by adding extra checks "is_next_command", is_com_multi, is_skip_flush". Also from readability/maintainability point, it would be good to remove the extra (and sometimes tricky, like recursve execution of dispatch_command) code.
It could be source of some very subtle bugs . MDEV-16308, protocol breakage that affects .NET connector, is possibly caused by COM_MULTI code (proof pending)
Attachments
Issue Links
- relates to
-
MDEV-10169 Optimize INSERT for COM_MULTI batch
-
- Closed
-
-
MDEV-16308 Out of sync with server
-
- Closed
-
To the backends discarding user packets after the first one, i.e Aurora
I'm quite sure that our protocol requires some pipelining capabilities, because there is a packet type that does not expect any reply from the server
https://dev.mysql.com/doc/internals/en/com-stmt-close.html .
That means, any number of COM_STMT_CLOSE can come from any prepared-statement-capable client (whether it uses pipelining knowingly or not), if it decides to close multiple prepared statements. Or of course there might be
COM_QUERY following COM_STMT_CLOSE. So, any client can send any number multiple packets without waiting for server reply. Thus discarding user input after COM_STMT_CLOSE would be fatal in general case.