CentOS 7

Load increase after the upgrade:

engine innodb status from one host:
MDEV-29988.engine_innodb_status.txt

In one location, we tested with 2 hosts, both getting abour the same amount of requests.

One host was still running 10.6.10 (dns04), usual load dns04_10.6.10.tar.gz

The other host was running 10.6.11 (dns01), high load dns01_10.6.11.tar.gz

Load graph for the 2 server from the previous comment:
green: 10.6.11 (dns01)
orange: 10.6.10 (dns04)

With the following patch:

--- a/mysql-test/main/mysql_client_test.test

+++ b/mysql-test/main/mysql_client_test.test

@@ -26,7 +26,7 @@ call mtr.add_suppression(" IP address .* could not be resolved");

 # var/log/mysql_client_test.trace

 --exec echo "$MYSQL_CLIENT_TEST" > $MYSQLTEST_VARDIR/log/mysql_client_test.out.log 2>&1

---exec $MYSQL_CLIENT_TEST --getopt-ll-test=25600M >> $MYSQLTEST_VARDIR/log/mysql_client_test.out.log 2>&1

+--exec $MYSQL_CLIENT_TEST test_mdev_16128 --getopt-ll-test=25600M >> $MYSQLTEST_VARDIR/log/mysql_client_test.out.log 2>&1

 # End of 4.1 tests

 echo ok;

--- a/tests/mysql_client_test.c

+++ b/tests/mysql_client_test.c

@@ -21053,6 +21053,7 @@ static void test_mdev_16128()

   rc= mysql_stmt_prepare(stmt, query, strlen(query));

   check_execute(stmt, rc);

+for (uint ii=0; ii < 10000; ii++) {

   memset(&bind, 0, sizeof(bind));

   bind.buffer_type= MYSQL_TYPE_STRING;

   bind.buffer_length= strlen(bind_arg_1);

@@ -21109,6 +21110,7 @@ static void test_mdev_16128()

     executed in PS-mode and bound with the value 'd' returns empty result set.

    */

   DIE_UNLESS(rc == MYSQL_NO_DATA);

+}

   mysql_stmt_close(stmt);

one can verify in the debugger that a new Item_string is allocated on the statement arena for every mysql_stmt_execute.

This means that memory is growing with every mysql_stmt_execute call and statement cleanup time is proportional to the number of mysql_stmt_execute calls.

In terms of regular MTR (but not for the regression suite!):

CREATE TABLE t (a VARCHAR(10)) CHARACTER SET utf8;

INSERT INTO t VALUES ('');

PREPARE stmt FROM "SELECT 1 FROM t WHERE a = ?";

--let $run= 100000

while ($run) {

  EXECUTE stmt USING 'x';

  --dec $run

}

select now(6);

DEALLOCATE PREPARE stmt;

select now(6);

DROP TABLE t;

total duration: 3.553 sec

deallocate duration: 0.000071 sec

max mem usage ~100M

total duration: 34.254 sec

deallocate duration: 0.003371 sec

max mem usage ~115M

The measurements are very rough as the test was run on a machine not tuned for performance experiments, they just give a general idea.

The difference scales a lot with the increase in the number of repetitions.

We could have a test for this in MTR where we do a similar loop as the above and then check that memory used for the user has not gone over 500K
Normally it should be < 100K and stay there.

Not this test, at least. Somebody would need to build a test which triggers the memory consumption more quickly.
This test takes ages to rise to a reliably detectable memory overuse. On the same machine, when I raised the number of repetitions from 100K to 1M, the test timed out on 10.3.37 with the regular MTR 15-min timeout, and by that time the memory use was still below 200M.

Would this bug cause the innodb_buffer to fill faster and be larger than needed?

No, this bug cannot cause that

We upgraded our customer production database this week, and we experienced major performance regression since we upgraded from 10.3 to 10.6.11. We have to tuned our a quite a few of our queries to achieve satisfactory performance.

Just "we too" comment.
We see very bad behaviors of 10.6 after upgrade from 10.3, namely tested versions 10.6.10 and 10.6.11. Both leaking memory like crazy. MariaDB is configured to use no more than 9GB of memory for maximum number of possible connections but it eats all (30GB RAM + 13GB swap) on one connection with project import and then crashes - killed by the OS because it is Out Of Memory. Details mentioned in MDEV-30096

For the record, my attempt to merge the fixes to 10.4 would cause incorrect evaluation of many WHERE conditions. I think that complex changes have to be tested in all relevant major branches before being pushed to any main branch.