Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-17610

Unexpected connection abort after certain operations from within stored procedure

Details

    Description

      CREATE PROCEDURE sp() ALTER TABLE non_existing_table OPTIMIZE PARTITION p0;
      		 
      CALL sp;
      		 
      SELECT 1;
      		 
       
      		 
      # Cleanup
      		 
      DROP PROCEDURE sp;

      Actual result

      		 
      MariaDB [test]> CREATE PROCEDURE sp() ALTER TABLE non_existing_table OPTIMIZE PARTITION p0;
      		 
      Query OK, 0 rows affected (0.04 sec)
      		 
       
      		 
      MariaDB [test]> CALL sp;
      		 
      +-------------------------+----------+----------+-----------------------------------------------+
      		 
      | Table                   | Op       | Msg_type | Msg_text                                      |
      		 
      +-------------------------+----------+----------+-----------------------------------------------+
      		 
      | test.non_existing_table | optimize | Error    | Table 'test.non_existing_table' doesn't exist |
      		 
      | test.non_existing_table | optimize | status   | Operation failed                              |
      		 
      +-------------------------+----------+----------+-----------------------------------------------+
      		 
      2 rows in set (0.00 sec)
      		 
       
      		 
      MariaDB [test]> select 1;
      		 
      ERROR 2013 (HY000): Lost connection to MySQL server during query

      Another example:

      CREATE PROCEDURE sp() SHOW USER_STATISTICS;
      		 
      CALL sp;
      		 
       
      		 
      SELECT "Still here" AS check_alive;
      		 
       
      		 
      # Cleanup
      		 
      DROP PROCEDURE sp;

      The server doesn't crash, it's really just a connection loss.
      The problem is also reproducible with 10.1 client + 10.2+ server, but does not seem to be reproducible with 10.2 client + 10.1 server (or 10.2 + 10.2 and higher).

      However, 10.2+ shows a different problem on the same test case, but with --ps-protocol:

      CREATE PROCEDURE sp() ALTER TABLE non_existing_table OPTIMIZE PARTITION p0;
      		 
      CALL sp;
      		 
      Table	Op	Msg_type	Msg_text
      		 
      test.non_existing_table	optimize	Error	Table 'test.non_existing_table' doesn't exist
      		 
      test.non_existing_table	optimize	status	Operation failed
      		 
      SELECT 1;
      		 
      bug2.ps1d                                [ fail ]
      		 
              Test ended at 2019-03-14 19:19:43
      		 
       
      		 
      CURRENT_TEST: bug2.ps1d
      		 
      mysqltest: At line 3: query 'SELECT 1' failed: 2031: No data supplied for parameters in prepared statement

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15800 Assertion `next_insert_id >= auto_inc_interval_for_cur_row.minimum()' failed in update_auto_increment() or unexpected ER_LOCK_DEADLOCK upon LOAD or INSERT

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            elenst Elena Stepanova added a comment -

            Assigning to serg for dispatching, I don't know to whom it should belong, if anyone.

            elenst Elena Stepanova added a comment - Assigning to serg for dispatching, I don't know to whom it should belong, if anyone.
            wlad Vladislav Vaintroub added a comment - - edited

            there is an extra OK packet sent by the server as part of CALL sp
            i.e there is

            • a resultset that does not end with STATUS_MORE_RESULTS_EXIST
            • an OK packet after this, that client does not expect

            client, after SELECT "Still here"

            • gets an OK packet it does not expect (from the previous CALL sp)
            • pkt_nr in this packet is 27 . In 5.5, client chokes on that, as it expects pkt_nr=1, and closes connection. In 10.2+, client does not close connection, but it still does not expect this OK packet.
            wlad Vladislav Vaintroub added a comment - - edited there is an extra OK packet sent by the server as part of CALL sp i.e there is a resultset that does not end with STATUS_MORE_RESULTS_EXIST an OK packet after this, that client does not expect client, after SELECT "Still here" gets an OK packet it does not expect (from the previous CALL sp) pkt_nr in this packet is 27 . In 5.5, client chokes on that, as it expects pkt_nr=1, and closes connection. In 10.2+, client does not close connection, but it still does not expect this OK packet.
            wlad Vladislav Vaintroub added a comment -

            Ok, the actual problem is the missing MORE_RESULTS_EXIST flag after result set

            wlad Vladislav Vaintroub added a comment - Ok, the actual problem is the missing MORE_RESULTS_EXIST flag after result set

            People

              wlad Vladislav Vaintroub
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              3 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.