MDEV-16708: Unsupported commands for prepared statementsbb-10.6-MDEV-16708-3

Within this task the following changes were made:
  - Added sending of metadata info in prepare phase for the admin related
    command (check table, checksum table, repair, optimize, analyze).

  - Refactored implementation of HELP command to support its execution in
    PS mode

  - Added support for execution of LOAD INTO and XA- related statements
    in PS mode

  - Modified mysqltest to enable any statements except PREPARE FROM,
    EXECUTE, EXECUTE IMMEDIATE, DEALLOCATE to be run in PS mode.

  - Fixed the following issues:
      The statement
        explain select (select 2)
      executed in regular and PS mode produces different results:

      MariaDB [test]> prepare stmt from "explain select (select 2)";
      Query OK, 0 rows affected (0,000 sec)
      Statement prepared
      MariaDB [test]> execute stmt;
      +------+-------------+-------+------+---------------+------+---------+------+------+----------------+
      | id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------------+
      |    1 | PRIMARY     | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | No tables used |
      |    2 | SUBQUERY    | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | No tables used |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------------+
      2 rows in set (0,000 sec)
      MariaDB [test]> explain select (select 2);
      +------+-------------+-------+------+---------------+------+---------+------+------+----------------+
      | id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra          |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------------+
      |    1 | SIMPLE      | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL | No tables used |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------------+
      1 row in set, 1 warning (0,000 sec)

      In case the statement
          CREATE TABLE t1 SELECT * FROM (SELECT 1 AS a, (SELECT a+0)) a
      is run in PS mode it fails with the error
          ERROR 1054 (42S22): Unknown column 'a' in 'field list'.

  - Uniform handling of read-only variables both in case the SET var=val
      statement is executed as regular or prepared statement.

  - Fixed assertion firing on handling LOAD DATA statement for temporary tables

  - Relaxed assert condition in the function lex_end_stage1() by adding
    the commands SQLCOM_ALTER_EVENT, SQLCOM_CREATE_PACKAGE,
    SQLCOM_CREATE_PACKAGE_BODY to a list of supported command

  - Removed raising of the error ER_UNSUPPORTED_PS in the function
    check_prepared_statement() for the ALTER VIEW command

  - Added initialisation of the data member st_select_lex_unit::last_procedure
    (assign NULL value) in the constructor

    Without this change the test case main.ctype_utf8 fails with the following
    report in case it is run with the option --ps-protocol.
      mysqltest: At line 2278: query 'VALUES (_latin1 0xDF) UNION VALUES(_utf8'a' COLLATE utf8_bin)' failed: 2013: Lost connection

  - The following bug reports were fixed:
        MDEV-24460: Multiple rows result set returned from stored
                    routine over prepared statement binary protocol is
                    handled incorrectly
        CONC-519: mariadb client library doesn't handle server_status and
                  warning_count fields received in the packet
                  COM_STMT_EXECUTE_RESPONSE.

    Reasons for these bug reports have the same nature and caused by
    missing loop iteration on results sent by server in response to
    COM_STMT_EXECUTE packet.

    Enclosing of statements for processing of COM_STMT_EXECUTE response
    in the construct like
      do
      {
        ...
      } while (!mysql_stmt_next_result());
    fixes the above mentioned bug reports.

 - Some tests has been disabled by the reason that they contains
   multi-statements that not supported in PS mode. Unfortunately,
   some of these multi-statements can't be converted to a sequence of
   single-statements by the reason that multi-statementness is
   a requirement for tests. Therefore the whole test file will be
   skipped in case it is run with --ps-protocol

1 files changed, 21 insertions, 1 deletions

diff --git a/sql/sql_binlog.cc b/sql/sql_binlog.cc
index 5cd70199645..bab2afb957a 100644
--- a/sql/sql_binlog.cc
+++ b/sql/sql_binlog.cc
@@ -354,8 +354,28 @@ void mysql_client_binlog_statement(THD* thd)
         (ev->flags & LOG_EVENT_SKIP_REPLICATION_F ?
          OPTION_SKIP_REPLICATION : 0);
 
-      err= ev->apply_event(rgi);
+      {
+        /*
+          For conventional statements thd->lex points to thd->main_lex, that is
+          thd->lex == &thd->main_lex. On the other hand, for prepared statement
+          thd->lex points to the LEX object explicitly allocated for execution
+          of the prepared statement and in this case thd->lex != &thd->main_lex.
+          On handling the BINLOG statement, invocation of ev->apply_event(rgi)
+          initiates the following sequence of calls
+            Rows_log_event::do_apply_event -> THD::reset_for_next_command
+          Since the method THD::reset_for_next_command() contains assert
+            DBUG_ASSERT(lex == &main_lex)
+          this sequence of calls results in crash when a binlog event is
+          applied in PS mode. So, reset the current lex temporary to point to
+          thd->main_lex before running ev->apply_event() and restore its
+          original value on return.
+        */
+        LEX *backup_lex;
 
+        thd->backup_and_reset_current_lex(&backup_lex);
+        err= ev->apply_event(rgi);
+        thd->restore_current_lex(backup_lex);
+      }
       thd->variables.option_bits=
         (thd->variables.option_bits & ~OPTION_SKIP_REPLICATION) |
         save_skip_replication;