| Showing entries 1 to 6 |
We just ran into a nasty InnoDB bug that only seems to exist in MySQL 5.5.25:
An InnoDB update that modifies a rows primary key can trigger some recursive behavior that creates new rows until all disk space is exceeded. This does not affect all primary key updates in general but only gets triggered when a few other conditions are also met, so you're not too likely to run into it, but if you do your mysqld server will waste a lot of IO bandwidth and storage space on this and will usually eventually run out of disk space.
The bug report for this, including a minimized test case, is:
and my current best guess is that it was introduced with the fix for
which changes some aspects
[Read more...]For those who saw my previous post about the crashing (regression) bug with SELECT COUNT(DISTINCT) on InnoDB with Primary Key (PK), you’ll be interested to know my test case does not crash in 5.5.18 (which was just released).
I’ve only tested my test case thus far, but it seems fine.
Unfortunately, the fix is not mentioned in the 5.5.18 changelogs though.
And there is no mention (yet, anyway) of a fix in the bug report I filed (though it was designated a ‘duplicate’, so it wouldn’t necessarily be updated).
I’m trying to get confirmation from the MySQL Dev Team on this (via the bug report), and will update this post if/when I hear anything.
I’ll also perform some of
[Read more...]In 5.5, a crashing, regression bug exists if you use SELECT COUNT(DISTINCT) *and* one of the WHERE operands is in the Primary Key (or just a unique index).
This simple crash (if only one row is in the table) will crash mysqld.
Of course I’ve filed a bug report, but that has been nearly 3 months and no updates yet.
Here is the bug I filed (which you won’t be able to view):
http://bugs.mysql.com/bug.php?id=61842
Really, the only thing that happened to my bug report was that it was designated a duplicate of another bug (which we also cannot view):
http://bugs.mysql.com/bug.php?id=61101
Based on the id, and the submitted dates of bugs 61100 and 61102, this initial bug (61101) was filed on May 9, 2011. So, in fact, this bug has been present for over 5
[Read more...]There seems to be an optimizer problem in 5.1, if you put a NULL in the IN clause of a SELECT. For example, given the following table:
CREATE TABLE foo (
a INT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (a)
);Compare these two EXPLAINs:
mysql> EXPLAIN * FROM foo WHERE a IN (160000, 160001, 160002)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: foo
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 3
Extra: Using where
1 row in set (0.06 sec)
mysql> EXPLAIN SELECT * FROM foo WHERE a IN (NULL, 160000, 160001, 160002)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: foo
type: ALL
possible_keys: PRIMARY
key: NULL [Read more...]
There’s a change of behaviour in MySQL 5.1.31 for Row Based Replication, if you have InnoDB transactions that also write to a MyISAM (or other non-transactional engine) table. It’s a side effect of fixing Bug #40116. Take this simple example:
Transaction 1: INSERT INTO myisam_tbl (item, val) VALUES (1, 0); Transaction 1: INSERT INTO innodb_tbl (item, val) VALUES (1, -1), (2, -1); Transaction 1: START TRANSACTION; Transaction 1: UPDATE myisam_tbl SET val=val+1 WHERE item=1; Transaction 1: UPDATE innodb_tbl SET val=( SELECT val FROM myisam_tbl WHERE item=1 ) WHERE item=1; Transaction 2: START TRANSACTION; Transaction 2: UPDATE myisam_tbl SET val=val+1 WHERE item=1; Transaction 2: UPDATE innodb_tbl SET val=( SELECT val FROM myisam_tbl WHERE item=1 ) WHERE[Read more...]
| Showing entries 1 to 6 |