A bug in MySQL submitted in June 2005 with a severity of “S2 (Serious)” remains unfixed 20 years later, causing both entertainment and despair in the community around this open source database manager.

Bug 11472 is described as “Triggers not executed following foreign key updates/deletes.” A trigger is code that runs automatically in response to an event such as an insert, update or delete in a specified table, and is typically used to enforce data integrity. The bug shows that if the specified table is updated indirectly, because of a relationship to another table, then the trigger does not execute.

Shortly after the bug was posted the team commented that it was a “known problem” and that “we will fix this in 5.1” but it was not fixed, though it was documented in the manual, which states that “cascaded foreign key actions do not activate triggers.”

Developers commenting to the bug report noted that the bug “is threatening ACID/integrity big time” and then in 2015 that “we just started suffering this issue after trying to implement triggers on cascade delete. Please a fix would be really appreciated.” ACID stands for Atomicity, Consistency, Isolation and Durablity.

In 2020 a young developer mentioned that “this bug is older than me.”

The bug is significant. In 2023 another developer mentioned that “we moved away from MySQL years ago – this bug was the last straw. We needed data integrity for a custom account platform.”

MySQL was acquired by Oracle in 2010 as part of Sun Microsystems, and although this particular bug pre-dates Oracle’s involvement, it could be perceived as evidence of neglect. Another argument is that long-standing and documented defects like this one are safer left unfixed, in case some application has come to depend on it, though in this example that looks unlikely.

MariaDB, a MySQL fork which dates back to the Oracle acquisition, also has this bug marked “unresolved”.

A discussion on Reddit includes a debate over whether use of triggers for database integrity is or is not best practice, and another common response, “the workaround is not using MySQL, but a sane relational db.” The most common alternative choice is PostgreSQL.

Another remarked that “at this point it’s a feature.”

According to the DB-Engines ranking, MySQL remains the second most widely used database manager behind Oracle, and ahead of Microsoft SQL Server in third place. MySQL is trending down though, and PostgreSQL is climbing. The ranking is based on mentions and job offers rather than actual usage data, so cannot be taken too seriously, but is some evidence of MySQL decline. 

Last year Percona’s Peter Zaitsev, who has worked with MySQL for many years, told The Register that “MySQL seems to suffer from years of neglect in the performance engineering department” and expressed his opinion that Oracle is sidelining the open source MySQL by making important new features exclusive to the cloud-based Heatwave.