Elena Stepanova added a comment - 2021-01-15 14:13 I can't reproduce it on a single machine either. It is possible that I was running 10.0 and 10.2 on different machines back then. I could have failed to mention it as I wouldn't expect it to be of any importance, but apparently it is. Below are the results I'm getting on Ubuntu Focal x86_64 vs Ubuntu Xenial x86_64. Both are running the same server from MariaDB 10.0.38 / 10.2.36 GLIBC_2.14 binary tarballs $ ls -l *gz -rw-rw-r-- 1 buildbot buildbot 447462919 Jan 30 2019 mariadb-10.0.38-linux-glibc_214-x86_64.tar.gz -rw-rw-r-- 1 buildbot buildbot 814589442 Nov 10 20:21 mariadb-10.2.36-linux-glibc_214-x86_64.tar.gz Focal MariaDB [test]> CHECKSUM TABLE badcs100, badcs100_53temp; + ----------------------+------------+ | Table | Checksum | + ----------------------+------------+ | test.badcs100 | 3449432362 | | test.badcs100_53temp | 3449432362 | + ----------------------+------------+ 2 rows in set (0.000 sec) Xenial MariaDB [test]> CHECKSUM TABLE badcs100, badcs100_53temp; + ----------------------+------------+ | Table | Checksum | + ----------------------+------------+ | test.badcs100 | 3088635921 | | test.badcs100_53temp | 3088635921 | + ----------------------+------------+ I don't know if it's expected.

Marko Mäkelä added a comment - 2021-10-12 07:54 Did anyone test this with Valgrind or MemorySanitizer, while disabling the questionable function Field_varstring::mark_unused_memory_as_defined() ? InnoDB will leave the unused part of VARCHAR buffers uninitialized when returning data to the SQL layer. That function (and equivalent Valgrind suppressions) are silencing warnings about uninitialized data being used.

Marko Mäkelä added a comment - 2021-10-12 08:20 I tested this with the following patch: diff --git a/sql/field.cc b/sql/field.cc index 08bde5f58e1..46e0a2e5954 100644 --- a/sql/field.cc +++ b/sql/field.cc @@ -7865,8 +7865,10 @@ bool Field_varstring::send(Protocol *protocol) #ifdef HAVE_MEM_CHECK void Field_varstring::mark_unused_memory_as_defined() { +#if 0 uint used_length __attribute__((unused)) = get_length(); MEM_MAKE_DEFINED(get_data() + used_length, field_length - used_length); +#endif } #endif and the following test case on a recent 10.5. But, it did not generate any messages about using uninitialized memory. I invoked Valgrind manually while passing the --manual-gdb option to mtr , so no suppressions should have been present. --source include/have_innodb.inc CREATE TABLE badcs ( bad_id int (10) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY , partner_id mediumint(8) NOT NULL , service_type varchar (50) NOT NULL , service_level tinyint(3) unsigned NOT NULL , service_start timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' , service_end timestamp NULL DEFAULT NULL , invoice tinyint(1) unsigned NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET utf8mb3;   INSERT INTO badcs VALUES (1, 123, 'CREATE TABLE badcs' , 5, '2018-03-02 10:48:23' , NULL , 1), (2, 123, 'zzzzzzzzzzzzz' , 4, '2018-03-02 10:48:46' , NULL , 1), (3, 255, 'trrrrrrrrrrrr' , 4, '2018-03-02 11:56:37' , NULL , 0); CHECKSUM TABLE badcs; DROP TABLE badcs; I got the same checksum reported when I invoked the test with ./mtr --mysqld=--innodb-default-row-format=redundant

Marko Mäkelä added a comment - 2021-10-12 08:22 For the record, the checksum that I got reported was 3379190625, which is differs from any checksums that were reported here earlier.

Michael Widenius added a comment - 2023-01-11 14:33 I also tested the original data and I got checksum 3379190625 (This with 11.0) I don't think the VARCHAR or blobs are a problem. The code in handler.cc:calculate_checksum() ensures that for BLOB, VARCHAR, GEOMETRY and BIT, we only calculate the checksum for the active data.