Planet MySQL
Planet MySQL -

  • Percona Server for MySQL 5.7.25-28 Is Now Available
    Percona is glad to announce the release of Percona Server 5.7.25-28 on February 18, 2019. Downloads are available here and from the Percona Software Repositories. This release is based on MySQL 5.7.25 and includes all the bug fixes in it. Percona Server 5.7.25-28 is now the current GA (Generally Available) release in the 5.7 series. All software developed by Percona is open-source and free. In this release, Percona Server introduces the variable binlog_skip_flush_commands. This variable controls whether or not FLUSH commands are written to the binary log. Setting this variable to ON can help avoid problems in replication. For more information, refer to our documentation. Note If you’re currently using Percona Server 5.7, Percona recommends upgrading to this version of 5.7 prior to upgrading to Percona Server 8.0. Bugs fixed FLUSH commands written to the binary log could cause errors in case of replication. Bug fixed #1827: (upstream #88720). Running LOCK TABLES FOR BACKUP followed by STOP SLAVE SQL_THREAD could block replication preventing it from being restarted normally. Bug fixed #4758. The ACCESS_DENIED field of the information_schema.user_statistics table was not updated correctly. Bug fixed #3956. MySQL could report that the maximum number of connections was exceeded with too many connections being in the CLOSE_WAIT state. Bug fixed #4716 (upstream #92108) Wrong query results could be received in semi-join sub queries with materialization-scan that allowed inner tables of different semi-join nests to interleave. Bug fixed #4907 (upstream bug #92809). In some cases, the server using the the MyRocks storage engine could crash when TTL (Time to Live) was defined on a table. Bug fixed #4911 Running the SELECT statement with the ORDER BY and LIMIT clauses could result in a less than optimal performance. Bug fixed #4949 (upstream #92850) There was a typo in trottling was replaced with throttling. Bug fixed #240. Thanks to Michael Coburn for the patch. MyRocks could crash while running START TRANSACTION WITH CONSISTENT SNAPSHOT if other transactions were in specific states. Bug fixed #4705, In some cases, mysqld could crash when inserting data into a database the name of which contained special characters (CVE-2018-20324). Bug fixed #5158. MyRocks incorrectly processed transactions in which multiple statements had to be rolled back. Bug fixed #5219. In some cases, the MyRocks storage engine could crash without triggering the crash recovery. Bug fixed #5366. When bootstrapped with undo or redo log encryption enabled on a very fast storage, the server could fail to start. Bug fixed #4958. Other bugs fixed: #2455, #4791, #4855, #4996, #5268. This release also contains fixes for the following CVE issues: CVE-2019-2534, CVE-2019-2529, CVE-2019-2482, CVE-2019-2434. Find the release notes for Percona Server for MySQL 5.7.25-28 in our online documentation. Report bugs in the Jira bug tracker.  

  • Deprecation of TLSv1.0 2019-02-28
    Ahead of the PCI move to deprecate the use of ‘early TLS’, we’ve previously taken steps to disable TLSv1.0. Unfortunately at that time we encountered some issues which led us to rollback these changes. This was to allow users of operating systems that did not – yet – support TLSv1.1 or higher to download Percona packages over TLSv1.0. Since then, we have been tracking our usage statistics for older operating systems that don’t support TLSv1.1 or higher at We now receive very few legitimate requests for these downloads. Consequently,  we are ending support for TLSv1.0 on all Percona web properties. While the packages will still be available for download from, we are unlikely to update them as the OS’s are end-of-life (e.g. RHEL5). Also, in future you will need to download these packages from a client that supports TLSv1.1 or greater. For example EL5 will not receive an updated version of OpenSSL to support versions greater than TLSv1.1. PCI has called for the deprecation of ‘early TLS’ standards. Therefore you should upgrade any EL5 installations to EL6 or greater as soon as possible. As noted in this support policy update by Red Hat, EL5 stopped receiving support under extended user support (EUS) in March 2015. To continue to receive updates for your OS and for any Percona products that you use, you need to update to more recent versions of CentOS, Scientific Linux, and RedHat Enterprise Linux. —Photo by Kevin Noble on Unsplash

  • 7 JavaScript Playgrounds to Use in 2019
    The importance of online code editing platforms cannot be overemphasized. As much as we love our local IDE's, one too many times we find ourselves needing to quickly share and or collaborate with a friend or colleague in our local projects. In cases like this, online playgrounds give us that added functionality to write and run codes as well as share snippets and have colleagues test it out and give us feedback. In this post, we'll be looking at the top 5 online code editors for JavaScript in no particular order. CodePen CodePen is an online social development environment for front-end developers. It comes fully equipped with all the features you'll need to build, test, share, collaborate and even deploy your websites. Plans and Features CodePen plans are flexible enough to accommodate whatever needs you might have. First, there are individual and team plans. Under the individual plans, you have a range of other plans that have been carefully structured to offer you a wide range of choices depending on what features are more important to you and on how much you can afford. The free plan has all you need to perform usual operations like creating pens, sharing snippets, running tests and so much more. If you're developing for experimental purposes or just building out your project for development purposes, the free plan has all you need. The PRO plan, however, adds a little bit to what you can do with CodePen. With CodePen PRO, you get unlimited privacy, asset hosting space, live view, embedded themes and so much more. On the PRO plan, you won't miss your local IDE. If you have specific needs for these features and you've got a few dollars to spare, then these plans are totally worth the price. You can visit the pricing page to have a closer look at what each plan offers to help you decide. However, that's not all, as we mentioned earlier, there's also a team plan for people working in teams. The price of the team plan is subject to the number of members in your team. However, it comes with a standard $12/month/member price. CodeSandbox CodeSandbox is an online editor that allows developers to focus on writing code while it handles all the necessary background processes and configurations. Unlike CodePen, CodeSandbox focuses more on building and sharing code demos that contain back-end components. The editor is optimized to analyze npm dependencies, show custom error messages, and also make projects searchable by npm dependency. CodeSandbox offers dedicated sandboxes to help developers quickly get started on developing with their favorite tools to build web applications. With CodeSandbox, all you need to do is open the browser, select your preferred development tool and start writing code. It abstracts all the backgrounds tasks and configurations so that you only need to worry about writing your code. With Condesandbox, we can do all of the following and more: Github integration With Codesanbox 2.0, you can commit, create repositories and open pull requests right from within CodeSandbox. Host static files CodeSandbox hosts all the files in the public directory for you. Previously this functionality didn't exist on CodeSandbox, but now, you can add static images, web workers, etc. As a result, you can imitate all the functionalities of your local development server as you now have full access to the index.html file. Real-time collaboration With CodeSandbox, you can create a project and open a Live Session to generate a live URL you can share to colleagues. Through the URL, all your colleagues can work together on the project at the same time. This may seem difficult to manage when the number grows, and you can't track what each person is doing. As a result, you can switch to a Classroom Mode where you can specify who can edit the sandbox and who can only view. Visual studio code integration CodeSandbox has a feature called VSCode in browser. It allows you access to VSCode features like keybindings, user snippets, breadcrumbs etc. All you need to do is copy your settings files directly from VSCode to CodeSandbox, and you will have control of all the files on your sandbox. These are only a handful of the features you'll get with CodeSandbox, there are more, like working in teams, Sandbox containers etc. I invite you to check them out their docs page for more. Back-end support It is worthy to note that CodeSandbox is one of the few online playgrounds that has support for back-end languages like Node.js. What's more? It has npm support. As a result of it, you can install any npm package you require in seconds. StackBlitz StackBlitz is a VSCode powered online playground for web developers. It offers developers the ability to create projects in just one click. The collaboration features of StackBlitz makes it possible to share a created project with colleagues through a unique project URL. Seamless project setup Like other playgrounds we've already mentioned, StackBlitz automatically takes care of all the background processes involved in setting up projects; like installing dependencies, compiling, bundling, etc. This way it abstracts the setup process for you so you can focus on what you do best, writing code. Stackblitz is renowned for its ability to handle Angular and React projects, all you need to set up a new of them is the click of a button. VSCode similarity Because VSCode powers StackBlitz, it comes packed with all the Aesthetic features we love in VSCode, giving you the look and feel of your local IDE. TypeScript support StackBlitz has TypeScript support and TypeScript auto-completion, a feature that is not found in other IDE's like Plunker. NPM support With StackBlitz, you can import any npm package into your project, just like you would in VSCode. Better still, you can copy snippets from documentation pages and blogs into the editor and it'll automatically detect the missing packages and prompt you to install them. Image credit to Eric Simons. Offline support Thanks to StackBlitz in-browser development server, you can continue writing code and editing your work even when offline. This gives you the superpower to build offline while leveraging the power of the online platform, killing two birds with one stone. We can't possibly go over all the perks, but you're welcome to see them yourself on the website. JS Fiddle JSFiddle is an online playground for creating, testing and showcasing collaborational HTML, CSS and JavaScript code snippets, known as 'fiddles'. It is one of the earliest playgrounds that laid the foundation for the creation of other modern-day playgrounds. At the moment, it may seem a bit basic compared to modern playgrounds like CodePen; however, it still performs basic playground operations like testing, sharing, and collaboration. As an added advantage, JSFiddle can also perform complex ajax simulations. JSFiddle lets you quickly get started by providing access to unique boilerplate templates for diverse technologies. As a result, it'll take you just about the click of a button to generate a boilerplate code for React, Vue or whichever technology you want. As much as JSFiddle behaves alike with other playgrounds, it has certain features that make it equally unique in its own way. Unlike most others, with JSFiddle, you can customize, add and use other JavaScript tools and frameworks easily. With the Togetherjs support, JSSFiddle offers an interactive user interface that lets users collaborate and share fiddles with colleagues. Moreso, it has inbuilt Git support. You can also use JSFiddle for any of the following: Bug reporting (test-case) for Github Issues Presenting code answers on Stack Overflow Live code collaboration Code snippets hosting JS BIN JSBin is a live playground for Html, CSS and JavaScript and a range of other preprocessors like jade, markdown and much more. It provides specific editor panels with an intuitive user interface for user interactivity. With JSBin, users can create bins, share, collaborate and test codes. JSBin is mostly focused on the ability to share code. It shares not just the code but also the complete output result of the code in the bin. It's real-time collaboration features lets colleagues view and see changes in real-time as you type in the editor panels. Though JSBin opens into a default Html code on start, there are many libraries available for you. You can add as many libraries as is required for your project to build your desired product. With JSBin, all created bins have a unique sharing Url that other users can join with to collaborate, fork and or edit the bin, while your original bin remains intact. Moreso, with JSBin, you can perform the following operations and more Export your bins as a gist live reload bins in editor and full preview Download bins Save snapshots of bins Templatize bins Archive bins etc JSBin also has a PRO plan that adds more functionality to what you can do. It gives an additional layer of features to extend your bin functionality. With The JSBin PRO, you can SSL embeds Custom embed CSS and editor settings Sandbox mode - does not save the bin Private bins Dropbox Vanity URLs - blog post Asset hosting Scrimba Scrimba is an entirely different kind of online playground than what we've seen so far. It offers you the ability to pause the video and edit the instructor's code and see the result in the editor. In-video interaction This provides an extra layer of interactivity to the usual playground functionality. Scrimba lets you take up an instructors demo and build it up into whatever use case you desire. In the playground mode, you can interact with the instructor's code however you please, and you can edit, copy, paste and basically perform any interactive operation you desire. Cross-platform Scrimba is completely cross-platform. It adapts to any screen size and arranges contents in both portrait and landscape mode to match your screens resolution requirements, this way, it constantly serves you the best visual output. Console and dependencies Scrimba has an in-built console that both the user and the instructor can access to run commands and debug code. You can log messages just the same way you would in any other editor. It also lets you install external dependencies into your project. What's better? the Scrimba team has designed the console in a way that you can see the console output with opening the console panel. Analytics Scrimbar has a sidebar notes features that track all the changes you make in the editor. This is a handy feature that gives you the ability to keep track of all your changes and refer to them in the future when the need be. Liveweaver Liveweaver is an online playground for Html, CSS, and JavaScript for web designers and developers. Like other editors we've come across, Liveweaver gives users the ability to create, test, and share code with colleagues. It opens into distinct editor panels for Html, CSS, JavaScript and Output panels respectively. One remarkable feature of Liveweaver is its simplicity. A newbie could easily open up Liveweaver, create a small app and run it without reading up any prior documentation. Moreso, Liveweaver supports a wide range of third-party libraries like Bootstrap, jQuery, Threejs etc. This helps developers build more robust applications without library support hinderances. Liveweave is free to use and comes packed with over 20 handy JavaScript libraries. With Liveweave, you can do all of the following and more Toggle live preview in editor panel Toggle light and dark mode for better viewing built-in ruler for measurements and aesthetics Collaborate with colleagues easily with the TeamUp feature Download weaves easily with a button click Supports SVG etc Conclusion In this post we have discussed five top online JavaScript editors you can use in 2019. Each playground has it's unique abilities so its difficult to choose a "best" one amongst them. We can, however, choose the one whose features best solves our needs. Disclaimer: This five online playgrounds discussed here are entirely my choice based on my own experience with them. There are other amazing online playgrounds like Plunker, CSS Deck, Dabblet, etc. If you have other playgrounds in mind, please do share them with us in the comments below. Hopefully, this post would help you pick the most suitable one for your needs.

  • Using FORCE INDEX: When Your Query Optimizer Gets It Wrong
    A Guest Post from Jordan Raine, Clio Jordan Raine is a staff software developer at Clio, the leading provider of legal practice management, client relationship management, and client intake software. Clio is dedicated to helping lawyers meet client needs and run efficient, profitable practices. Jordan wrote this post to help mySQL developers save time/effort and ultimately improve their customers' experience.  Unlike most code a developer writes, writing SQL only requires us to describe what data we want and not how to get it. When given a query like SELECT id, author_id FROM posts WHERE author_id = 123 ORDER BY id, you needn’t concern yourself with what indexes are used (if any), what type of sort is used, or any other number of implementation details. Instead, the query optimizer handles this for you. This keeps SQL concise and readable and, for the most part, the query optimizer chooses the best path for a given set of data. But sometimes the query optimizer gets it wrong. Let’s look at one example of this and what to do about it. We have a blog app that pulls from a posts table that looks like this: CREATE TABLE `posts` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `body` text, `author_id` bigint(20) NOT NULL, `coauthor_id` bigint(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `index_posts_on_author_id` (`author_id`), KEY `index_posts_on_coauthor_id` (`coauthor_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 ``` Our app is doing really great and there are over 100 million rows in the posts table. Unfortunately, the coauthor feature wasn’t as popular as expected and is rarely used: mysql> SELECT COUNT(*) FROM posts WHERE coauthor_id IS NOT NULL;+----------+| COUNT(*) | +----------+ | 159286 | +----------+ 1 row in set (0.04 sec) Only about 0.01% of the posts have a coauthor, leaving 99.9% of the rows NULL. When MySQL calculates index statistics, the coauthor_id index comes back with extremely low cardinality: only 29! mysql> show indexes from posts; +-------+------------+----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |Index_comment | +-------+------------+----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ | posts | 0 | PRIMARY | 1 | id | A | 112787604 | NULL | NULL | | BTREE | || | posts | 1 | index_posts_on_author_id | 1 | author_id | A | 2891989 | NULL | NULL | | BTREE | | | | posts | 1 | index_posts_on_coauthor_id | 1 | coauthor_id | A | 29 | NULL | NULL | YES | BTREE | ||+-------+------------+----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+ 3 rows in set (0.00 sec)``` When an index has such low cardinality, MySQL is less likely to use it. After all, what’s the point of an index that can eliminate very few values? However, even with such low cardinality, the query optimizer chooses to use it when looking up posts by a coauthor: mysql> EXPLAIN SELECT * FROM posts WHERE coauthor_id = 98543\G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: posts type: ref possible_keys: index_posts_on_coauthor_id key: index_posts_on_coauthor_id key_len: 9 ref: const rows: 2 Extra: NULL 1 row in set (0.00 sec)mysql> SELECT * FROM posts WHERE coauthor_id = 98543; +----------+--------------+-----------+-------------+ | id | body | author_id | coauthor_id | +----------+--------------+-----------+-------------+ | 21168595 | Lipsum Lorem | 1 | 98543 | | 25695860 | Lipsum Lorem | 99833 | 98543 | +----------+--------------+-----------+-------------+ 2 rows in set (0.01 sec) ``` This even works when looking up multiple coauthors in a single query: mysql> EXPLAIN SELECT * FROM posts WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842)\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: posts type: range possible_keys: index_posts_on_coauthor_id key: index_posts_on_coauthor_id key_len: 9 ref: NULL rows: 19 Extra: Using index condition1 row in set (0.00 sec) mysql> SELECT * FROM posts WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842); +-----------+--------------+-----------+-------------+ | id | body | author_id | coauthor_id | +-----------+--------------+-----------+-------------+ | <results removed for bevity> | +-----------+--------------+-----------+-------------+ 19 rows in set (0.01 sec)``` But things go off the rails when we add an extra ID to the IN clause: mysql> EXPLAIN SELECT * FROM posts WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842,98511)\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: posts type: ALL possible_keys: index_posts_on_coauthor_id key: NULL key_len: NULL ref: NULL rows: 112787604 Extra: Using where 1 row in set (0.01 sec)mysql> SELECT * FROM posts WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842,98511); +-----------+--------------+-----------+-------------+ | id | body | author_id | coauthor_id | +-----------+--------------+-----------+-------------+ | <results removed for brevity> | +-----------+--------------+-----------+-------------+ 21 rows in set (37.39 sec)``` Instead of using an index, the query optimizer has decided to scan the entire table. What happened? To understand why this happens, we need to look at how MySQL picks an index. Generally, the best index is the one that matches the fewest rows. To estimate how many rows will be found in each index for a given query, the query optimizer can use one of two methods: using “dives” into the index or using index statistics. Index dives — counting entries in an index for a given value — provides accurate row count estimates because an index dive is done for each index and value (e.g., for an IN with 10 values, it performs 10 index dives). This can degrade performance. Using index statistics avoids this problem, providing near constant time lookups by reading the table’s index statistics (i.e., cardinality). (More detail on how this is done can be found here.) In other words: slow and accurate or fast and sloppy. For tables with evenly distributed data, the latter works great. However, when an index is sparsely populated, like with coauthor_id, index statistics can be wildly inaccurate. In cases like this, we can lend a hand using index hints like USE INDEX and FORCE INDEX. Let’s start with USE INDEX , which according to the documentation, “tells MySQL to use only one of the named indexes to find rows in the table”: mysql> EXPLAIN SELECT * FROM posts USE INDEX(index_posts_on_coauthor_id) WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842,98511)\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: posts type: ALL possible_keys: index_posts_on_coauthor_id key: NULL key_len: NULL ref: NULL rows: 112787604 Extra: Using where 1 row in set (0.00 sec)``` This recommendation wasn't enough; MySQL still decided it was better to use no index at all. Let’s try again but this time use FORCE INDEX, which “acts like USE INDEX, with the addition that a table scan is assumed to be very expensive”: mysql> EXPLAIN SELECT * FROM posts FORCE INDEX(index_posts_on_coauthor_id) WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842,98511)\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: posts type: range possible_keys: index_posts_on_coauthor_id key: index_posts_on_coauthor_id key_len: 9 ref: NULL rows: 37761660 Extra: Using index condition 1 row in set (0.00 sec)mysql> SELECT * FROM posts FORCE INDEX(index_posts_on_coauthor_id) WHERE coauthor_id IN (98543,99592,99096,98022,99643,99091,98578,99910,99910,98842,98511); +-----------+--------------+-----------+-------------+ | id | body | author_id | coauthor_id | +-----------+--------------+-----------+-------------+ | <results removed for brevity> | +-----------+--------------+-----------+-------------+ 21 rows in set (0.00 sec)``` Thankfully, this does the trick, coercing the optimizer into a query plan we know to be more performant. Instead of 37 seconds, the query finishes in less than 1ms! But why did the behavior change when adding one more ID to the query above, increasing it from 10 to 11 values? In MySQL 5.6, a new variable called eq_range_index_dive_limit was added, setting a threshold for equality ranges like IN.  mysql> SHOW VARIABLES LIKE 'eq_range_index_dive_limit'; +---------------------------+-------+ | Variable_name | Value | +---------------------------+-------+ | eq_range_index_dive_limit | 10 | +---------------------------+-------+ 1 row in set (0.00 sec) ``` By default, it is set to 10 in MySQL 5.6 and was increased to 200 in MySQL 5.7.4.  While intended to improve performance by reducing index dives, this variable surprised some teams − including my own − by significantly degrading performance of certain queries. When a routinely run query degrades in performance by 10,000x overnight, your database quickly becomes occupied entirely by those queries, grinding your app and your business to a halt. There’s a detailed look at one example of this from the MySQL at Facebook blog. The query optimizer has been tuned to handle the most common data shapes and, in most cases, will choose a good query plan. However, when this is not the true, FORCE INDEX provides a way to influence the choices of the query optimizer. However, this heavy-handed approach comes with added responsibility: you’re now responsible to specify what data you want and how MySQL should retrieve it. As data evolves and new queries are introduced, the index you’ve forced MySQL to use may no longer be best. It’s worth considering why the optimizer chooses a catastrophic query plan. In our example, based on a real world system, the shape of our data poorly fit the schema we’d chosen. Instead of continuing to optimize the query using FORCE INDEX, it may be time to roll up our sleeves and change the schema.   Jordan Raine, Staff Software Developer at Clio, is a full-stack web developer who loves to write code and solve interesting problems. He particularly enjoys Ruby/Rails backends, in addition to work in Java. Jordan also has extensive HTML, CSS, and JavaScript frontend experience. Whenever possible, he welcomes the opportunity to participate in open sourcing projects and contribute back to the community.  

  • Fun with Bugs #79 - On MySQL Bug Reports I am Subscribed to, Part XV
    More than 3 weeks passed since my previous review of public MySQL bug reports I am subscribed to, so it's time to present some of the bugs I've considered interesting in January, 2019.As usual, I'll review them starting from the oldest and try to summarize my feelings about these bugs at the end of this post. Here they are: Bug #93806 - "Document error about ON DUPLICATE KEY UPDATE". Years pass, but fine MySQL manual still does not explain some cases of InnoDB locking properly. Xiaobin Lin found yet another case that it does not explain properly. Or, maybe, the manual is correct and the problem in the implementation? MariaDB 10.3.7 shows the same behavior. Bug #93827 - "dict_index_has_desc() is not efficient". Yet another bug report from Zhai Weixiang. I see 50 still active bug reports from him! Maybe Oracle should send some nice T-shirts to top N most productive bug reporters? Bug #93845 - "Optimizer choose wrong index, sorting index instead of filtering index". yet another bug report of a known class, this time from Daniele Renda. It's good example of optimizer trace usage to make a point. Note also that using ANALYZE ... UPDATE HISTOGRAMS does not help. As a side note, implementation of optimizer trace for MariaDB is finally in progress and should be done for upcoming 10.4. See MDEV-6111 for the details if you care. Bug #93875 - "mysqldump per-table dump is slow since 5.7 on instances with many tables". This performance regression bug (that was "verified" without adding the regression tag) was reported by Nikolai Ikhalainen from Percona. This bug report is a nice example of using Docker to create easily repeatable test cases for bug reports. Bug #93878 - "innodb_status_output fails to restore to old value". This great bug report from Yuhui Wang  not only describes 3 cases when InnoDB status is printed to the error log automatically, but also shows that in one of these cases, when we can not found free block in the buffer pool in 20 loops, this printing is not stopped after the problem is resolved, and provides a patch that resolves the problem. See also his nice Bug #94065 - "MySQL fails to startup when setting persist variable" with detailed analysis of the problem. Bug #93917 - "Wrong binlog entry for BLOB on a blackhole intermediary master". Nice corner case was found by Sveta Smirnova from Percona. With her 52 "Verified" bug reports at the moment she also deserves a T-shirt from Oracle as one of top bug reporters! Bug #93922 - "UNION ALL very slow with SUM(0)". This weird bug was found and reported by Sergio Paternoster. He had to spend notable efforts to see this bug "Verified"... Bug #93948 - "XID inconsistency on master-slave with CTAS". Krunal Bauskar from Percona noted this inconsistency in XID generation on slave vs master. Let's wait and check if it ends up as "Not a bug". Bug #93957 - "slave_compressed_protocol doesn't work with semi-sync replication in MySQL-5.7". This bug report from Pavel Katiushyn also looks like a regression, as similar bug was fixed in older 5.7.x release. But I do not see any public comment with verification attempt neither in recent 5.7, nor in recent 8.0 (where older bug also had to be fixed). So, the bug is "verified", but the real impact and versions affected are not clear. Bug #93963 - "Slow query log doesn't log a slow CREATE INDEX with admin statements enabled". This clear and properly tagged regression vs MySQL 5.7 was reported by Jeremy Smyth. Bug #93986 - "Transactions in serializable mode are not actually serializable". I've subscribed to this bug report mostly for (expected) fun of reading further comments. It's still "Need feedback", but single comment so far is worth reading. Bug #94121 - "Enable hardware CRC32 under Valgrind". Laurynas Biveinis from Percona also provided a patch for this 8 years old problem. Bug #94130 - "XA COMMIT may lead replication broken". Yet another proof that XA transactions implementation is broken in MySQL. This time from Phoenix Zhang and in semi-sync replication case. This photo reminds me current state of MySQL bugs processing in Oracle - it seems there is no clear and straightforward way to follow. Everything is fuzzy these days... There are few more bugs reported in January, 2019 that I am watching, but their status is not yet clearly defined, so I decided to skip them in this review.To summarize:  Oracle engineers who process bugs still do not add regression tag to many regression bugs. This is a shame, really. If I were their boss I'd make this a policy and one of important KPI values to monitor. In some cases bugs get verified immediately without any demonstrated attempt to show how the check was performed, while in other cases poor bug reporters have to fight hard to re-make their point and get a real check done. It seems these days good old approaches to bugs verification are not followed strictly by some Oracle engineers.

Copyright © 2019 Global Relief Center. All Rights Reserved.