Fun with Bugs #82 - On MySQL Bug Reports I am Subscribed to, Part XVIII

I've got few comments to my post on references to MariaDB in MySQL bug reports (not in the blog, but via social media and in personal messages), and all but one comments from current and former colleagues whose opinion I value a lot confirmed that this really looks like a kind of attempt to advertise MariaDB. So, from now on I'll try to keep my findings on how tests shared by MySQL bug reporters work in MariaDB for myself, MariaDB JIRA and this blog (where I can and will advertise whatever makes sense to me), and avoid adding them to MySQL bug reports.

That said, I still think that it's normal to share links to MariaDB bug reports that add something useful (like patches, explanations or better test cases), and I keep insisting that this kind of feedback should not be hidden. Yes, I want to mention Bug #94610 (and related MDEV-15641) again, as a clear example of censorship that is not reasonable and should not be tolerated.

In the meantime, since my previous post in this series I've subscribed to 30 or so new MySQL bug reports. Some of them are listed below, started from the oldest. This time I am not going to exclude "inactive" reports that were not accepted by Oracle MySQL engineers as valid:

• Bug #94629 - "no variable can skip a single channel error in mysql replication". This is a request to add support for per-channel options to skip N transactions or specific errors. It is not accepted ("Not a Bug") just because one can stop replication on all channels and start on one to skip transaction(s) there, then resume replication for all channels. Do you really think this is a right and only way to process such a report?
• Bug #94647 - "Memory leak in MEMORY table by glibc". This is also not a bug because one ca use something like malloc-lib=jemalloc with mysqld_safe or Environment="LD_PRELOAD=/path/to/jemalloc" with systemd services. There might be some cost related to that in older versions... Note that similar MDEV-14050 is still open.
• Bug #94655 - "Some GIS function do not use spatial index anymore". yet another regression vs MySQL 5.7 reported by Cedric Tabin. It ended up verified as feature request without a regression tag...
• Bug #94664 - "Binlog related deadlock leads to all incoming connection choked.". This report from Yanmin Qiao ended up as a duplicate of  Bug #92108 - "Deadlock by concurrent show binlogs, pfs session_variables table & binlog purge" (fixed in MySQL 5.7.25+, thanks Sveta Smirnova for the hint). See also Bug #91941.
• Bug #94665 - "enabling undo-tablespace encryption doesn't mark tablespace encryption flag". Nice finding by Krunal Bauskar from Percona.
• Bug #94699 - "Mysql deadlock and bugcheck on aarch64 under stress test". Bug report with a patch contributed by Cai Yibo. The fix is included in upcoming MySQL 8.0.17 and the bug is already closed.
• Bug #94709 - "Regression behavior for full text index". This regression was reported by Carlos Tutte and properly verified (with regression tag added and all versions checked) by Umesh Shastry. See also detailed analysis of possible reason in the comment from Nikolai Ikhalainen.
• Bug #94723 - "Incorrect simple query result with func result and FROM table column in where". Michal Vrabel found this interesting case when MySQL 8.0.215 returns wrong results. I've checked the test case on MariaDB 10.3.7 and it is not affected. Feel free to consider this check and statement my lame attempt to advertise MariaDB. I don't mind.
• Bug #94730 - "Kill slave may cause start slave to report an error.". This bug was declared a duplicate of a nice Bug #93397 - "Replication does not start if restart MySQL after init without start slave." reported by Jean-François Gagné earlier. Both bugs were reported for MySQL 5.7.x, but I do not see any public attempt to verify if MySQL 5.6 or 8.0 is also affected. In the past it was required to check/verify bug on all GA versions supported if the test case applies. Nowadays this approach is not followed way too often, even when bug reporter cared enough to provide MTR test case.
• Bug #94737 - "MySQL uses composite hash index when not possible and returns wrong result". Yet another optimizer bug was reported by Simon Banaan. Again, MariaDB 10.3.7 is NOT affected. I can freely and happily state this here if it's inappropriate to state so in the bug report itself. By the way, other MySQL versions were probably not checked. Also, unlike Oracle engineer who verified the bug, I do not hesitate to copy/paste the entire results of my testing here:
  

  MariaDB [test]> show create table tmp_projectdays_4\G*************************** 1. row ***************************
         Table: tmp_projectdays_4
  Create Table: CREATE TABLE `tmp_projectdays_4` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `project` int(11) NOT NULL,
    `datum` date NOT NULL,
    `voorkomen` tinyint(1) NOT NULL DEFAULT 1,
    `tijden` tinyint(1) NOT NULL DEFAULT 0,
    `personeel` tinyint(1) NOT NULL DEFAULT 0,
    `transport` tinyint(1) NOT NULL DEFAULT 0,
    `materiaal` tinyint(1) NOT NULL DEFAULT 0,
    `materiaaluit` tinyint(1) NOT NULL DEFAULT 0,
    `materiaalin` tinyint(1) NOT NULL DEFAULT 0,
    `voertuigen` varchar(1024) DEFAULT '',
    `medewerkers` varchar(1024) DEFAULT '',
    `personeel_nodig` int(11) DEFAULT 0,
    `personeel_gepland` int(11) DEFAULT 0,
    `voertuigen_nodig` int(11) DEFAULT 0,
    `voertuigen_gepland` int(11) DEFAULT 0,
    `created` datetime DEFAULT NULL,
    `modified` datetime DEFAULT NULL,
    `creator` int(11) DEFAULT NULL,
    PRIMARY KEY (`id`),
    KEY `project` (`project`,`datum`) USING HASH
  ) ENGINE=MEMORY AUTO_INCREMENT=2545 DEFAULT CHARSET=utf8mb4
  1 row in set (0.001 sec)
  
  MariaDB [test]> explain SELECT COUNT(1) FROM `tmp_projectdays_4` WHERE `project`
   IN(15409,15911,15929,15936,16004,16005,16007,16029,16031,16052,16054,16040,1248
  5,15892,16035,16060,16066,16093,16057,16027,15988,15440,15996,11457,15232,15704,
  12512,12508,14896,15594,16039,14997,16058,14436,16006,15761,15536,16016,16019,11
  237,13332,16037,14015,15537,15369,15756,12038,14327,13673,11393,14377,15983,1251
  4,12511,13585,12732,14139,14141,12503,15727,15531,15746,15773,15207,13675,15676,
  15663,10412,13677,15528,15530,10032,15535,15693,15532,15533,15534,15529,16056,16
  064,16070,15994,15918,16045,16073,16074,16077,16069,16022,16081,15862,16048,1606
  2,15610,15421,16001,15896,15004,15881,15882,15883,15884,15886,16065,15814,16076,
  16085,16174,15463,15873,15874,15880,15636,16092,15909,16078,15923,16026,16047,16
  094,16111,15914,15919,16041,16063,16068,15971,16080,15961,16038,16096,16127,1564
  1,13295,16146,15762,15811,15937,16150,16152,14438,16086,16156,15593,16147,15910,
  16106,16107,16161,16132,16095,16137,16072,16097,16110,16114,16162,16166,16175,16
  176,16178,15473,16160,15958,16036,16042,16115,16165,16167,16170,16177,16185,1582
  3,16190,16169,15989,16194,16116,16131,16157,16192,16197,16203,16193,16050,16180,
  16209,15522,16148,16205,16201,15990,16158,16216,16033,15974,16112,16133,16181,16
  188,16189,16212,16238,16241,16183,15640,15638,16087,16088,16129,16186,16164,1610
  8,15985,16244,15991,15763,16049,15999,16104,16208,13976,16122,15924,16046,16242,
  16151,16117,16187);
  +------+-------------+-------------------+------+---------------+------+--------
  -+------+------+-------------+
  | id   | select_type | table             | type | possible_keys | key  | key_len
   | ref  | rows | Extra       |
  +------+-------------+-------------------+------+---------------+------+--------
  -+------+------+-------------+
  |    1 | SIMPLE      | tmp_projectdays_4 | ALL  | project       | NULL | NULL
   | NULL | 2544 | Using where |
  +------+-------------+-------------------+------+---------------+------+--------
  -+------+------+-------------+
  1 row in set (0.004 sec)
  
  MariaDB [test]> SELECT COUNT(1) FROM `tmp_projectdays_4` WHERE `project` IN(1540
  9,15911,15929,15936,16004,16005,16007,16029,16031,16052,16054,16040,12485,15892,
  16035,16060,16066,16093,16057,16027,15988,15440,15996,11457,15232,15704,12512,12
  508,14896,15594,16039,14997,16058,14436,16006,15761,15536,16016,16019,11237,1333
  2,16037,14015,15537,15369,15756,12038,14327,13673,11393,14377,15983,12514,12511,
  13585,12732,14139,14141,12503,15727,15531,15746,15773,15207,13675,15676,15663,10
  412,13677,15528,15530,10032,15535,15693,15532,15533,15534,15529,16056,16064,1607
  0,15994,15918,16045,16073,16074,16077,16069,16022,16081,15862,16048,16062,15610,
  15421,16001,15896,15004,15881,15882,15883,15884,15886,16065,15814,16076,16085,16
  174,15463,15873,15874,15880,15636,16092,15909,16078,15923,16026,16047,16094,1611
  1,15914,15919,16041,16063,16068,15971,16080,15961,16038,16096,16127,15641,13295,
  16146,15762,15811,15937,16150,16152,14438,16086,16156,15593,16147,15910,16106,16
  107,16161,16132,16095,16137,16072,16097,16110,16114,16162,16166,16175,16176,1617
  8,15473,16160,15958,16036,16042,16115,16165,16167,16170,16177,16185,15823,16190,
  16169,15989,16194,16116,16131,16157,16192,16197,16203,16193,16050,16180,16209,15
  522,16148,16205,16201,15990,16158,16216,16033,15974,16112,16133,16181,16188,1618
  9,16212,16238,16241,16183,15640,15638,16087,16088,16129,16186,16164,16108,15985,
  16244,15991,15763,16049,15999,16104,16208,13976,16122,15924,16046,16242,16151,16
  117,16187);
  +----------+
  | COUNT(1) |
  +----------+
  |     2544 |
  +----------+
  1 row in set (0.025 sec)
  
  MariaDB [test]> select version();
  +--------------------+
  | version()          |
  +--------------------+
  | 10.3.7-MariaDB-log |
  +--------------------+
  1 row in set (0.021 sec)

  When the job was done properly I see no reasons NOT to share the results.
• Bug #94747 - "4GB Limit on large_pages shared memory set-up". My former colleague Nikolai Ikhalainen from Percona noted this nice undocumented "feature" (Had I forgotten to advertise Percona recently? Sorry about that...) He proved with a C program that one can create shared memory segments on Linux large than 4GB, one just had to use proper data type, unsigned long integer, in MySQL's code. Still, this report ended up as non-critical bug in "MySQL Server: Documentation" category, or even maybe a feature request internally. What a shame!

Spring in Paris is nice, as this photo made 3 years ago proves. The way MySQL bug reports are handled this spring is not any nice in some cases.

To summarize:

1. It seems recently the fact that there is some limited workaround already published somewhere is a good enough reason NOT to accept valid feature request. Noted.
2. Regression bugs (reports about drop in performance or problem that had not happened with older version but happens with some recent) are still not marked with regression tag sometimes. Moreover, clear performance regressions in MySQL 8.0.x vs MySQL 5.7.x may end up as just feature requests... A request to "Make MySQL Great Again" maybe?
3. MySQL engineers who verify bugs often do not care to check all major versions and/or share the results of their tests. This is unfortunate.
4. Some bugs are not classified properly upon verification. The fact that wrong data type is used is anything but severity 3 documentation problem, really.