Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.6.0
    • Server
    • 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

          Activity

            wlad Vladislav Vaintroub added a comment - - edited

            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.

            wlad Vladislav Vaintroub added a comment - - edited 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.
            wlad Vladislav Vaintroub added a comment - @sanja, could you take a look ? https://github.com/MariaDB/server/commit/035f2b7d0a7865b1815511b387228db789fabfdb

            aparently, it is already done

            wlad Vladislav Vaintroub added a comment - aparently, it is already done
            sanja Oleksandr Byelkin added a comment - - edited

            wlad did you pushed without review?

            sanja Oleksandr Byelkin added a comment - - edited wlad did you pushed without review?

            yep, this was pushed with some other patch, from my bb-10.6-wlad .
            Sorry, happened. But this was already in review status for a long time.

            wlad Vladislav Vaintroub added a comment - yep, this was pushed with some other patch, from my bb-10.6-wlad . Sorry, happened. But this was already in review status for a long time.

            People

              sanja Oleksandr Byelkin
              wlad Vladislav Vaintroub
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.