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

Error after update to 10.5.8 on CentOS-8: DBD::mysql::st execute failed: Unknown MySQL error

Details

    Description

      Error after update to 10.5.8 on CentOS-8:

      DBD::mysql::st execute failed: Unknown MySQL error

      By perl-DBI-1.641-3.module_el8.1.0+199+8f0a6bbd.x86_64:

      $DBh = DBI->connect("DBI:mysql:$DBName:$DBHost:$DBPort", $DBUser, $DBPasswd, {"mysql_enable_utf8" => 1});

      Restart of MariaDB service fixes the issue for a few minutes and it reappears.

      Please investigate ASAP.

      Now I see same update for my CentOS-7 servers and I'm afraid to install it.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-17832 Protocol: extensions for Pluggable types and JSON, GEOMETRY

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 21 older comments
            monty Michael Widenius added a comment - - edited

            The user informed me that changing a table used in the SELECT to use utf8mb4 instead of utf8mb3 caused the problem to disappear for a while (worked for a few days)

            The user has the following character sets active:
            The user have

            show variables like "character%";
            		 
            +--------------------------+----------------------+
            		 
            | Variable_name            | Value                |
            		 
            +--------------------------+----------------------+
            		 
            | character_set_client     | utf8mb3              |
            		 
            | character_set_connection | utf8mb3              |
            		 
            | character_set_database   | latin1               |
            		 
            | character_set_filesystem | binary               |
            		 
            | character_set_results    | utf8mb3              |
            		 
            | character_set_server     | utf8mb4              |
            		 
            | character_set_system     | utf8mb3              |
            		 
            | character_sets_dir       | /usr/share/charsets/ |
            		 
            +--------------------------+----------------------

            monty Michael Widenius added a comment - - edited The user informed me that changing a table used in the SELECT to use utf8mb4 instead of utf8mb3 caused the problem to disappear for a while (worked for a few days) The user has the following character sets active: The user have show variables like "character%"; +--------------------------+----------------------+ | Variable_name | Value | +--------------------------+----------------------+ | character_set_client | utf8mb3 | | character_set_connection | utf8mb3 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8mb3 | | character_set_server | utf8mb4 | | character_set_system | utf8mb3 | | character_sets_dir | /usr/share/charsets/ | +--------------------------+----------------------
            monty Michael Widenius added a comment -

            I found the issue:
            The user was connecting to MariaDB 10.6 from old and new clients (some that supports EXTENDED_METADATA and some that didn't).
            The QUERY_CACHE was on and the query and response was cached.
            If now a user with a different value for EXTENDED_METADATA executed the same query, the old response where sent to the user, but this is wrong as the packet is different in this case.

            Temporary workaround for anyone having this problem:
            set have_query_cache=NO

            Fix for the server:
            Store the EXTENDED_METADATA flag in the query cache and compare this before sending the result back to the client

            monty Michael Widenius added a comment - I found the issue: The user was connecting to MariaDB 10.6 from old and new clients (some that supports EXTENDED_METADATA and some that didn't). The QUERY_CACHE was on and the query and response was cached. If now a user with a different value for EXTENDED_METADATA executed the same query, the old response where sent to the user, but this is wrong as the packet is different in this case. Temporary workaround for anyone having this problem: set have_query_cache=NO Fix for the server: Store the EXTENDED_METADATA flag in the query cache and compare this before sending the result back to the client
            bar Alexander Barkov added a comment -

            monty, please review a patch:

            https://github.com/MariaDB/server/commits/bb-10.5-bar-MDEV-24487

            Thanks.

            bar Alexander Barkov added a comment - monty , please review a patch: https://github.com/MariaDB/server/commits/bb-10.5-bar-MDEV-24487 Thanks.
            bar Alexander Barkov added a comment -

            Approved by Monty on slack.

            bar Alexander Barkov added a comment - Approved by Monty on slack.
            andrewponomarenko Andrey P. added a comment -

            Great work, guys! Thanks a lot!

            andrewponomarenko Andrey P. added a comment - Great work, guys! Thanks a lot!

            People

              bar Alexander Barkov
              andrewponomarenko Andrey P.
              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.