Showing entries 1 to 9
Displaying posts with tag: mysql bugs (reset)
Thanks, Oracle, for fixing the stupid and dangerous SET GLOBAL sql_log_bin!

As of MySQL 5.5.41, released on November 28 (last week), Oracle has fixed MySQL Bug 67433, which I filed on October 31, 2012 and wrote about 4 months ago in Stupid and dangerous: SET GLOBAL sql_log_bin. You can see the fix in Launchpad revision 4718.

The MySQL 5.5.41 release notes mention:

Replication: The global scope for the sql_log_bin system variable has been deprecated, and this variable can now be set with session scope only. The statement SET GLOBAL SQL_LOG_BIN now produces an error. It remains possible for now to read the global value of sql_log_bin, but you …

[Read more]
Stupid and dangerous: SET GLOBAL sql_log_bin

It’s been almost 4.5 years since, during some code refactoring, it was decided (or accidentally changed?) that sql_log_bin should become a GLOBAL variable as well as a SESSION one. Almost 2 years ago, during MySQL 5.5 upgrades at Twitter, I filed MySQL Bug 67433 describing in detail how stupid and dangerous this change was, and asking for a reversal.

Nothing has been changed or reversed, so SET GLOBAL sql_log_bin continues to be allowed. I continue to directly see, and hear about damage caused by incorrect use of SET GLOBAL sql_log_bin. So, let me describe just how stupid and dangerous it really is.

What really happens when you run SET GLOBAL sql_log_bin?

If you have a master-slave replication configuration, your master will have binary logging enabled (log_bin) and be recording each transaction to its local binary logs, which the slaves read (more or …

[Read more]
Another Idea to Help Foster a Vibrant Community: Please make all bugs public

Since MySQL recently implemented the following feature request (and discussed here and here) to help foster communication among public bugs and feature requests, and to provide a way to allow the Community to voice whether or not a bug affects them, I decided to file another feature request that I think would even further encourage communication amongst an already vibrant community, and that is to simply:

“Please make all bugs public”

http://bugs.mysql.com/bug.php?id=69642

And thanks to the new bugs feature, if you would like to see this implemented as well, please click on the …

[Read more]
InnoDB bugs found during research on InnoDB data storage

During the process of researching InnoDB’s storage formats and building the innodb_ruby and innodb_diagrams projects discussed in my series of InnoDB blog posts, Davi Arnaut and I found a number of InnoDB bugs. I thought I’d bring up a few of them, as they are fairly interesting.

These bugs were largely discoverable due to the innodb_space utility making important internal information visible in a way that it had never been visible in the past. Using it to examine production tables provided many leads to go on to find the bugs responsible. When we initially looked at a graphical plot of free space by page produced from innodb_space data, we were quite surprised to see so many …

[Read more]
How InnoDB accidentally reserved only 1 bit for table format

The MySQL 5.5 (and 5.6) documentation says, in Identifying the File Format in Use:

“… Otherwise, the least significant bit should be set in the tablespace flags, and the file format identifier is written in the bits 5 through 11. …”

This is incorrect for any version due to a bug in how the tablespace flags were stored (which caused only 1 bit to be reserved, rather than 6). This was all re-worked in MySQL 5.6, so someone obviously noticed it, but the documentation has been left incorrect for all versions, and the incorrect and misleading code has been left in MySQL 5.5. I filed MySQL Bug #68868 about the documentation.

File formats and names

There are file format names in the documentation and code for values 0 through 25 (letters …

[Read more]
Bugs Page for MySQL and Friends

After completing my recent ‘downloads‘ page (similar to my ‘changelogs‘, ‘documentation‘, and ‘server variables‘ pages), it occurred to me that I should add a ‘bugs‘ page as well.

So, I’ve added a bug page, which has links to the main bug listing/reporting pages for MySQL, MariaDB (Aria), Drizzle, Percona Server (XtraDB), Xtrabackup, Sphinx, MONyog, and SQLyog (thus far).

Bug Page:

http://www.chriscalender.com/?page_id=876

Hope this helps.

[Read more]
The community helping customers restore faster with mysqldump

A big thanks to Xiaobin Lin for taking the time to submit and the related patch for bug #64248. The patch is based on 5.5.20
This should help users to restore their database faster thanks to fast index creation. More information is available via the bugs page. I have heard that this is just one of several patches he has contributed.
Contributions such as this, help MySQL to continue to deliver an always improving product.
So a big “Thank You” from the MySQL team.

Bugs and Spam don't mix

A big thank you to the MySQL web team and engineers for helping combat spam and keeping the bugs.mysql.com site spam free.

reCaptcha is now installed and is a requirement when adding a comment to a current bug. We want the community to be able to review and comment on bugs with little spam as possible getting in the way.

A General Purpose Dynamic Cursor - Part 2 of 3

Permalink: http://bit.ly/RcRieg



Refer to part 1 for the rationale behind the code or you can skip to part 3 for a working example as well as how you can debug the stored procedure.

Important: The SP will create a table named `dynamic_cursor`. Make sure this table does not exist in the database where you will be storing the procedure. Here's the 1st iteration of a general purpose dynamic cursor:

DELIMITER $$
DROP PROCEDURE IF EXISTS `dynamicCursor` $$
CREATE DEFINER=`root`@`localhost` PROCEDURE `dynamicCursor`(
IN selectStmt TEXT,
IN whatAction VARCHAR(255),
INOUT …
[Read more]
Showing entries 1 to 9