Blog of (former?) MySQL Entomologist: spatial

Showing posts with label spatial. Show all posts

Thursday, April 4, 2019

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-François Gagné 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:

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.
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?
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.
Some bugs are not classified properly upon verification. The fact that wrong data type is used is anything but severity 3 documentation problem, really.

Saturday, March 9, 2019

Fun with Bugs #81 - On MySQL Bug Reports I am Subscribed to, Part XVII

Two weeks passed since my previous review of public MySQL bug reports I consider interesting enough to subscribe to them. Over this period I picked up a dozen or so new public bug reports that I'd like to briefly review today.

Here is my recent subscriptions list, starting from the oldest bug reports:

Bug #94431 - "Can't upgrade from 5.7 to 8.0 if any database have a hyphen in their name". It seems one actually needs a database like that created in MySQL 5.6 with at least one InnoDB table having FULLTEXT index to hit the problem. Great finding by Phil Murray. Note that after several unsuccessful attempts by others the bug was eventually reproduced and verified by Jesper Wisborg Krogh. Let's hope we'll see it fixed in MySQL 8.0.16.
Bug #94435 - "mysql command hangs up and cosume CPU almost 100%". It was reported by Masaaki HIROSE, whose previous related/similar Bug #94219 - "libmysqlclient enters and infinite loop and consume CPU usage 100%" ended up as "Not a bug" (wrongly, IMHO, as nobody cared enough to reproduce the steps instead of commenting on their correctness and checking something else). Bug reporter had not only insisted and provided all the details, but also tried to analyze the reasons of the bug and provided links to other potentially related bug reports (Bug #88428 - "mysql_real_query hangs with EINTR errno (using YASSL)" and Bug #92394 - "libmysqlclient enters infinite loop after signal (race condition)"). Great job and nice to see the bug "Verified" eventually.
Bug #94441 - "empty ibuf aio reads in innodb status". This regression vs MySQL 5.6 was noted by Nikolai Ikhalainen from Percona. MariaDB 10.3.7 is also affected, unfortunately:
...
I/O thread 9 state: native aio handle (write thread)
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,
ibuf aio reads:, log i/o's:, sync i/o's:Pending flushes (fsync) log: 0; buffer pool: 0
1344 OS file reads, 133 OS file writes, 2 OS fsyncs
...
Bug #94448 - "Rewrite LOG_BLOCK_FIRST_REC_GROUP during recovery may be dangerous.". Yet another MySQL 8 regression (not marked with "regression" tag) was found by Kang Wang.
Bug #94476 - "mysql semisync replication stuck with master in Waiting to finalize termination". It has "Need feedback" status at the moment. I've subscribed to this report from Shirish Keshava Murthy mostly to find out how a report that may look like a free support request will be processed by Oracle engineers. Pure curiosity, for now.
Bug #94504 - "AIO::s_log seems useless". This problem was reported by Yuhui Wang. It's a regression in a sense that part of the code is no longer needed (and seems not to be used) in MySQL 8, but still remains.
Bug #94541 - "Assertion on import via Transportable Tablespace". This bug reported by Daniël van Eeden was verified based on code review and some internal discussion. We do not know if any other version besides 5.7.25 is affected, though. The assertion itself:
```
InnoDB: Failing assertion: btr_page_get_prev(next_page, mtr) == btr_pcur_get_block(cursor)->page.id.page_no()
```
does not seem to be unique. We can find it in MDEV-18455 also (in other context).
Bug #94543 - "MySQL does not compile with protobuf 3.7.0". I care about build/compiling bugs historically, as I mostly use MySQL binaries that I built myself from GitHub source. So, I've immediately subscribed to this bug report from Laurynas Biveinis.
Bug #94548 - "Optimizer error evaluating JSON_Extract". This bug was reported by Dave Pullin. From my quick test it seems MariaDB 10.3.7 is also affected. Error message is different in the failing case, but the point is the same - the function is not evaluated if the column from derived table that is built using the function is not referenced in the SELECT list. This optimization is questionable and may lead to hidden "bombs" in the application code.
Bug #94550 - "generated columns referring to current_timestamp fail". I tried to check simple test case in this bug report by Mario Beck on MariaDB 10.3.7, but it does not seem to accept NOT NULL constraint for generated stored columns at all:
```
MariaDB [test]> CREATE TABLE `t2` (
    ->   `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    ->   `content` varchar(42) DEFAULT NULL,
    ->   `bucket` tinyint(4) GENERATED ALWAYS AS ((floor((to_seconds(`created_at
`) / 10)) % 3)) STORED NOT NULL);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that
corresponds to your MariaDB server version for the right syntax to use near 'NOT
 NULL)' at line 4
```
I do not see this option in formal syntax described here as well. But in case of MariaDB we can actually make sure the generated column is never NULL by adding CHECK constraint like this:
MariaDB [test]> CREATE TABLE `t2` (    ->   `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    ->   `content` varchar(42) DEFAULT NULL,
    ->   `bucket` tinyint(4) GENERATED ALWAYS AS ((floor((to_seconds(`created_at`) / 10)) % 3)) STORED);
Query OK, 0 rows affected (0.434 sec)

MariaDB [test]> INSERT INTO t2 (content) VALUES ("taraaaa");
Query OK, 1 row affected (0.070 sec)

MariaDB [test]> alter table t2 add constraint cnn CHECK (`bucket` is NOT NULL);
Query OK, 1 row affected (1.159 sec)
Records: 1 Duplicates: 0 Warnings: 0

MariaDB [test]> INSERT INTO t2 (content) VALUES ("tarabbb");
Query OK, 1 row affected (0.029 sec)

MariaDB [test]> INSERT INTO t2 (content) VALUES ("");
Query OK, 1 row affected (0.043 sec)

MariaDB [test]> select * from t2;
+---------------------+---------+--------+
| created_at          | content | bucket |
+---------------------+---------+--------+
| 2019-03-09 17:28:03 | taraaaa |      0 |
| 2019-03-09 17:29:43 | tarabbb |      1 |
| 2019-03-09 17:29:50 |         |      2 |
+---------------------+---------+--------+
3 rows in set (0.002 sec)

MariaDB [test]> show create table t2\G*************************** 1. row ***************************
       Table: t2
Create Table: CREATE TABLE `t2` (
`created_at` timestamp NOT NULL DEFAULT current_timestamp(),
`content` varchar(42) DEFAULT NULL,
`bucket` tinyint(4) GENERATED ALWAYS AS (floor(to_seconds(`created_at`) / 10)
MOD 3) STORED,
CONSTRAINT `cnn` CHECK (`bucket` is not null)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.011 sec)
So, maybe after all we can state that MariaDB is NOT affected.
Bug #94552 - "innodb.virtual_basic fails when valgrind is enabled". I still wonder if anyone in Oracle runs MTR test suite on Valgrind-enabled (-DWITH_VALGRIND=1 cmake option) at least in the process of official release (and if they check the failures). It seems not to be the case based on this bug report from Manuel Ung.
Bug #94553 - "Crash in trx_undo_rec_copy". Bernardo Perez noted that as a side effect of still "Verified" Bug #82734 - "trx_undo_rec_copy needlessly relies on buffer pool page alignment" (that affects both MySQL 5.7 and 8.0) we may get crashes while working with generated columns. I hope to see them both fixed soon, but for now Bug #94553 has status "Need Feedback", probably in a hope to get a repeatable test case. I'll watch it carefully.
Bug #94560 - "record comparison in spatial index non-leaf rtree node seems incorrect". I doubt spatial indexes of InnoDB are widely used, and I have no doubts there are many bugs waiting to be discovered in this area. This specific bug was reported by Jie Zhou who had also suggested a fix.
Bug #94610 - "Server stalls because ALTER TABLE on partitioned table holds dict mutex". My former colleague Justin Swanhart reported this bug just yesterday, so no wonder it is not verified yet. It refers to a well known verified old Bug #83435 - "ALTER TABLE is very slow when using PARTITIONED table" (that I've also subscribed to immediately) from Roel Van de Paar, affecting both MySQL 5.6 and 5.7. I hope to see this bug verified and fixed soon, as recently I see this kind of state for main thread:
```
Main thread process no. 3185, id 140434206619392, state: enforcing dict cache limit
```
too often in INNODB STATUS outputs to my liking...

As you could note, I still try to check (at least in some cases) if MariaDB is also affected by the same problem. I think it's a useful check both for me (as I work mostly with MariaDB as a support engineer) and for the reader (to know if switching to MariaDB may help in any way or if there are any chances for MariaDB engineers to contribute anything useful, like a fix).

"Hove, actually". For years residents of Hove used this humorous reply when they live in Brighton... "Regression, actually" is what I want to say (seriously) about every other MySQL bug report I subscribe to... So, you see Hove and many regression bugs above!

To summarize:

Sometimes Oracle engineers demonstrate proper collective effort to understand and carefully verify public bug reports. Good to know they are not ready to give up fast!
I have to copy-paste this item from my previous post. As the list above proves, Oracle engineers still do not use "regression" tag when setting "Verified" status for obviously regression bugs. I think bug reporters should care then to always set it when they report regression of any kind.
It seems there no regular MTR test runs for Valgrind builds performed by Oracle engineers, or maybe they just ignore failures.

Sunday, January 20, 2019

Fun with Bugs #77 - On MySQL Bug Reports I am Subscribed to, Part XIV

Slides for my talk about MySQL bugs at FOSDEM 2019 MySQL, MariaDB and Friends Devroon are ready, support customers decided not to break anything badly on weekend, so I have some free time for blogging. As usual, when I do not have any better idea or useful recent real life experience to share I write about MySQL bugs.

Today I'd like to continue my review of interesting MySQL bug reports added by Community members in December, 2018. I'll review them starting from the oldest:

Bug #93701 - "Assertion `maybe_null' failed |Item_func_concat::val_str(String*)". It's debug assertion, not a big deal (S6 bug), so why should anyone care about this report from Ramesh Sivaraman? Because last time same assertion failure ended up as serious enough Bug #83115 fixed in 8.0.11.
Bug #93708 - "Page Cleaner will sleep for long time if clock changes". In this bug report from Marcelo Altmann I was mostly impressed by arguing started by Oracle engineer on bug severity (documentation request, feature request vs real bug). IMHO it was a waste of time.
Bug #93728 - "mysqld crash after using alter table with SPATIAL key". Nice finding by Rui Xu. Unfortunately MariaDB 10.3.7 is also affected. At least in the error log I also see this error message for each SPATIAL index of the table:
2019-01-20 19:26:15 9 [ERROR] InnoDB: Record in index `idx2` of table `test`.`tab` was not found on update: TUPLE (info_bits=0, 2 fields): {[32]      $@      $@
      $@      $@(0x0000000000000400000000000000040000000000000004000000000000000
400),[4]    (0x00000001)} at: COMPACT RECORD(info_bits=0, 1 fields): {[8]infimum
(0x090E06090D050D00)}
Bug #93734 - "MySQL 8.0 is 36 times slower than MySQL 5.7". I like everything about this bug reported by Vadim Tkachenko, CTO of Percona. I like synopsis that sounds cool, missing exact MySQL 8.0.x version (but I suspect 8.0.13), impact of innodb_flush_log_at_trx_commit, suggested fix and the fact that the bug is still "Open" and nobody from Oracle paid any attention to the report from CTO of one of key Oracle partners and supporters of MySQL 8. Wonderful!
Bug #93737 - "mysqlbinlog mermory used grows unstoped". I had not tried to reproduce it (and nobody had it seems, as the bug is still "Open"), but this report by Chandler Bong sounded interesting. Let's see what it may end up with...
Bug #93746 - "MySQL Crashes with deadlock at Mutex DICT_SYS created dict0dict.cc:1172". Long semaphore waits involving DICT_SYS mutex and leading to watchdog thread killing MySQL are common. Bug processing is still in progress, but I subscribed to this bug by Anton Ravich mostly to follow another bug he refers to as a possibly related, Bug #80919. That bug is declared a duplicate of some bug in Oracle's internal bugs database, without bug number mentioned. This is not the first time I see such am artistic way to process community bugs (that I consider totally wrong and unacceptable).
Bug #93760 - "InnoDB got assert failure while figuring out space id at startup". Fungo Wang found this crash while running MTR test case innodb.innodb_redo_debug_1 with debug binaries. Now I wonder if Oracle QA runs MTR tests with debug binaries at all and do they care to check failures (or rely on Percona for this activity)? Any comments?
Bug #93761 - "optimize table cause the slave MTS deadlock!". Sounds interesting and serious, but nobody cared to check this bug report. It's "Open" without comments for 3 weeks already.
Bug #93767 - "INSTALL COMPONENT fails - handled segfault during installation nothing in log". I am surprised that somebody outside of Oracle already uses new MySQL 8.0 server components feature. My former colleague, Justin Swanhart, tried but failed so far. Let's see how this report may end up. For now Oracle engineer stated that Justin tried to do something this framework was not designed for, see nice last comment there.
Bug #93777 - "the Originator of mysql.event is not correct". Pay attention to this bug found by Dennis Gao if you use events in replication environment.
Bug #93779 - "dml in table with trigger to other Table map in binlog lead to slave sql stopped". Work on this bug report from Mohamed Atef is still in progress. Bug reported cared to add a lot of details in recent comments, so I hope to see this bug processed soon.

I've also included a couple of bugs reported in January, 2019 in the list above, but I hope you don't mind.

Today I'd like to remember those sunny days in Venice in September and those pesky MySQL bugs reported this winter...

To summarize:

Some bug reports stay "Open" for weeks without any good reason recently.
The shameful practice of referring to bugs in Oracle's internal bugs database without giving a number (that we see in release notes when the bug is fixed and can look for in commit messages at GitHub) should be stopped! Next time I'll blame engineer(s) who this by name, here and in social media. Check how this is properly done by Shane Bester.
I wonder if Oracle QA runs MTR tests cases on debug builds on a regula basis and checks the results, or this is now a job for Percona mostly?
I should write a separate blog post about bugs related to SPATIAL indexes implementation in InnoDB. There should be dragons...

P.S. Don't forget to click on names of bug reporters to see the entire list of still active MySQL bug reports each of them created.