Alice Sherepa added a comment - 2025-01-27 15:13 - edited Could you please provide more details on how to repeat the issue and attach your .cnf file(s) It works as expected on my machine with 11.4.2, also tried fiddle with 11.4.4

Daniil added a comment - 2025-01-28 12:30 - edited Thank you for waiting! Took me a while to retrieve and combine the .cnf files. It's a galera cluster, and the issue won't reproduce if I start a transaction first. The configuration: [client-server] socket = /run/mysqld/mysqld.sock [client] [client-mariadb] [mariadb-client] [mariadb-upgrade] [mariadb-admin] [mariadb-binlog] [mariadb-check] [mariadb-dump] [mariadb-import] [mariadb-show] [mariadb-slap] [server] [mariadbd] pid-file = /run/mysqld/mysqld.pid basedir = /usr datadir = /mysql/data port = 3307 lc_messages_dir = /usr/share/mysql lc_messages = en_US skip-external-locking skip-name-resolve bind-address = 0.0.0.0 max_connections = 1500 connect_timeout = 5 wait_timeout = 600 max_allowed_packet = 16M thread_cache_size = 128 sort_buffer_size = 4M bulk_insert_buffer_size = 16M tmp_table_size = 32M max_heap_table_size = 32M myisam_recover_options = BACKUP key_buffer_size = 128M table_open_cache = 400 myisam_sort_buffer_size = 512M concurrent_insert = 2 read_buffer_size = 2M read_rnd_buffer_size = 1M query_cache_limit = 128K query_cache_size = 64M log_warnings = 2 log_error = /var/log/mysql/error.log log_slow_query_file = /var/log/mysql/mariadb-slow.log log_slow_query_time = 10 log_slow_verbosity = query_plan log_bin = /mysql/binlog/mysql-bin.log expire_logs_days = 10 binlog_row_image = FULL binlog_cache_size = 32K max_binlog_size = 100M expire_logs_days = 7 character-set-server = utf8mb4 character-set-collations = utf8mb4=uca1400_ai_ci default_storage_engine = InnoDB innodb_buffer_pool_size = 16G innodb_log_buffer_size = 8M innodb_file_per_table = 1 innodb_open_files = 400 innodb_io_capacity = 400 innodb_flush_method = O_DIRECT   [embedded] [mariadbd] [mariadb-11.4]   [galera] binlog_format=ROW default-storage-engine=innodb innodb_autoinc_lock_mode=2 bind-address=0.0.0.0 wsrep_on=ON wsrep_provider=/usr/lib/galera/libgalera_smm.so wsrep_cluster_name="[some-string-here-removed]" wsrep_node_name="[some-string-here-removed]" wsrep_node_address="[some-ip-here-removed]" wsrep_cluster_address="gcomm://[some-ip-here-removed],[some-ip-here-removed],[some-ip-here-removed]" wsrep_slave_threads=1 wsrep_certify_nonPK=1 wsrep_max_ws_rows=0 wsrep_max_ws_size=2147483647 wsrep_debug=0 wsrep_convert_LOCK_to_trx=0 wsrep_retry_autocommit=1 wsrep_auto_increment_control=1 wsrep_drupal_282555_workaround=0 wsrep_causal_reads=0 wsrep_notify_cmd= wsrep_sst_method=mariabackup wsrep_sst_auth=[some-string-here-removed] [mariadb] aria-encrypt-tables encrypt-binlog encrypt-tmp-disk-tables encrypt-tmp-files loose-innodb-encrypt-log loose-innodb-encrypt-tables

Ramesh Sivaraman added a comment - 2025-01-29 07:30 daniil_arora could not reproduce the issue locally on galera cluster using given configuration, without starting a transaction. could you please share the OS info? MariaDB [test]> set @b := UUID(); Query OK, 0 rows affected (0.001 sec)   MariaDB [test]> select @b; + --------------------------------------+ | @b | + --------------------------------------+ | 8ed6521b-de0b-11ef-ad02-0800278dc04d | + --------------------------------------+ 1 row in set (0.000 sec)   MariaDB [test]> select @b; + --------------------------------------+ | @b | + --------------------------------------+ | 8ed6521b-de0b-11ef-ad02-0800278dc04d | + --------------------------------------+ 1 row in set (0.000 sec)   MariaDB [test]> select @b; + --------------------------------------+ | @b | + --------------------------------------+ | 8ed6521b-de0b-11ef-ad02-0800278dc04d | + --------------------------------------+ 1 row in set (0.000 sec)   MariaDB [test]> select version(); + --------------------------+ | version() | + --------------------------+ | 11.4.2-MariaDB-deb10-log | + --------------------------+ 1 row in set (0.000 sec)   MariaDB [test]>

Daniil added a comment - 2025-01-29 09:29 @ramesh sure: Operating System: Ubuntu 24.04 LTS Kernel: Linux 6.8.0-31-generic Architecture: x86-64 Please ask if you need something specific.

Ramesh Sivaraman added a comment - 2025-01-29 17:54 - edited daniil_arora thank you for the info, could not reproduce this issue locally on Ubuntu 24.04 either. Could you please share more details about the reproducibility steps, for example, did you see this issue with every new session before initiating any transaction? Also please share the sample transaction you executed that made it impossible to reproduce this problem? I have tested it on the physical machine, please let me know if any other configuration changes are required apart from the given configuration. MariaDB [test]> \! cat /etc/os-release | head -4 PRETTY_NAME="Ubuntu 24.04.1 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.1 LTS (Noble Numbat)" MariaDB [test]> MariaDB [test]> set @b := UUID(); Query OK, 0 rows affected (0.000 sec)   MariaDB [test]> select @b; +--------------------------------------+ | @b | +--------------------------------------+ | 38a7f69a-de66-11ef-8c5b-2aea64ff733c | +--------------------------------------+ 1 row in set (0.000 sec)   MariaDB [test]> select @b; +--------------------------------------+ | @b | +--------------------------------------+ | 38a7f69a-de66-11ef-8c5b-2aea64ff733c | +--------------------------------------+ 1 row in set (0.000 sec)   MariaDB [test]> select @b; +--------------------------------------+ | @b | +--------------------------------------+ | 38a7f69a-de66-11ef-8c5b-2aea64ff733c | +--------------------------------------+ 1 row in set (0.000 sec)   MariaDB [test]> select version(); +----------------------------+ | version() | +----------------------------+ | 11.4.2-MariaDB-ubu2404-log | +----------------------------+ 1 row in set (0.000 sec)   MariaDB [test]>

Elena Stepanova added a comment - 2025-02-26 22:31 - edited The provided config file cannot be complete, at least because it contains encryption settings (including InnoDB log encryption), but no key management plugin configuration, so InnoDB shouldn't even start, and since it's a default engine, neither should the server. Of course encryption is unrelated, but there can be something else in the config files. Given that the result looks as if @b is treated as a string "UUID()", that is, in SELECT statements it is expanded to the function name and only then executed, and adding to it the extremely slow execution time (0.035 for just selecting a variable – that's a lot), one wild suspicion that comes to mind is that instead of the client program a wrapper is run, and it performs adjustments to the queries. Or it can be expanded into a stored function which, in turn, returns UUID(). Or maybe it can somehow be done via a non-default pager. Another mildly interesting but likely unrelated oddity is the duration formatting (comma in 0,035). Maybe it's just a locale thing. A few experiments can rule out most obvious theories. 1) check what the client program resolves to, 2) enable the general log to see what queries the server actually receives to rule out tampering with the queries, 3) instead of selecting the variable, insert its value into a table, to rule out tampering with results.

Daniil added a comment - 2025-02-28 08:47 - edited @elenst 1) mysql --version gives me that: mysql Ver 15.1 Distrib 10.6.18-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper 2) Sounds weird, who or what could be tampering with results? Moreover, it works fine in a transaction. 3) Initialy was inserting in a table and the generated UUID was a primary key. It was silently failing to insert a new row with the same primary key. Whatever, I suppose it's totally fine to use a transaction in the case of such an issue. Therefore, I fine with the issue being closed as non-reproducible.