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

Minor LOAD INDEX output inconsistencies under XA

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • 10.6, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5(EOL), 10.7(EOL)
    • 10.6
    • Storage Engine - InnoDB, XA
    • None

    Description

      Whilst it does not seem to affect operation/data, the "Corrupt" error in the output below looks to be incorrect:

      10.7.0 57f14eab20ae2733eb341f3d293515a10a40bc48 (Debug)

      10.7.0-dbg>XA START 'a';
      Query OK, 0 rows affected (0.000 sec)
       
      10.7.0-dbg>LOAD INDEX INTO CACHE t KEY(PRIMARY);
      +--------+--------------+----------+------------------------------+
      | Table  | Op           | Msg_type | Msg_text                     |
      +--------+--------------+----------+------------------------------+
      | test.t | preload_keys | Error    | Table 'test.t' doesn't exist |
      | test.t | preload_keys | status   | Operation failed             |
      +--------+--------------+----------+------------------------------+
      2 rows in set (0.000 sec)
       
      10.7.0-dbg>XA END 'a';
      Query OK, 0 rows affected (0.000 sec)
       
      10.7.0-dbg>LOAD INDEX INTO CACHE t KEY(PRIMARY);
      +--------+--------------+----------+-------------------------------------------------------------------------------------------+
      | Table  | Op           | Msg_type | Msg_text                                                                                  |
      +--------+--------------+----------+-------------------------------------------------------------------------------------------+
      | test.t | preload_keys | Error    | XAER_RMFAIL: The command cannot be executed when global transaction is in the  IDLE state |
      | test.t | preload_keys | Error    | XAER_RMFAIL: The command cannot be executed when global transaction is in the  IDLE state |
      | test.t | preload_keys | error    | Corrupt                                                                                   |
      +--------+--------------+----------+-------------------------------------------------------------------------------------------+
      3 rows in set (0.000 sec)
      

      Furthermore, the output in 10.2 (and 10.3) for the same commands is somewhat different (single XAER_RMFAIL output instead of repeated):

      10.2.38 (Debug)

      10.2.38-dbg>LOAD INDEX INTO CACHE t KEY(PRIMARY);
      +--------+--------------+----------+-------------------------------------------------------------------------------------------+
      | Table  | Op           | Msg_type | Msg_text                                                                                  |
      +--------+--------------+----------+-------------------------------------------------------------------------------------------+
      | test.t | preload_keys | Error    | XAER_RMFAIL: The command cannot be executed when global transaction is in the  IDLE state |
      | test.t | preload_keys | error    | Corrupt                                                                                   |
      +--------+--------------+----------+-------------------------------------------------------------------------------------------+
      2 rows in set (0.00 sec)
      

      10.4, 10.5 and 10.6 also have double repeated XAER_RMFAIL messages. It is not clear why the messages are repeated now (could be a regression). It also does matter if the table exists or not, the output is the same.

      Attachments

        Issue Links

          Activity

            People

              Elkin Andrei Elkin
              Roel Roel Van de Paar
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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