Slashdot Mirror
A Tale of Two MySQL Bugs
New submitter Archie Cobbs writes "Last May I encountered a relatively obscure performance bug present in both MySQL 5.5.x and MariaDB 5.5.x (not surprising since they share the same codebase). This turned out to be a great opportunity to see whether Oracle or the MariaDB project is more responsive to bug reports. On May 31 Oracle got their bug report; within 24 hours they had confirmed the bug — pretty impressive. But since then, it's been radio silence for 3 months and counting. On July 25, MariaDB got their own copy. Within a week, a MariaDB developer had analyzed the bug and committed a patch. The resulting fix will be included in the next release, MariaDB 5.5.33."
mysql is of historical curiosity. At best.
Why would Oracle fix a bug in something they're trying to kill off?
A sample size of one is insufficient to make any meaningful conclusions.
Anyone up for scraping the two bug trackers and finding more identical bug reports?
Well, DONTGIVEAFUCK is one of the statuses on their Bugzilla. Just sayin'.
Small projects can be about purity. Making the best possible code base you can. Especially ones where people work on it for free -- they wouldn't be working on it if they didn't deeply believe in it.
Large corporations have different goals. The success of a changeset is not measured in how many bugs you fix or even how many features you add, but how much positive impact your paying customers and shareholders perceive.
The NSA took its own time to plant backdoors in the vulnerable systems, or forgot to reply back to Oracle that they finally can roll the fix.
If he would have the right intention to measure response time both bug reports should have been filed at the same time... filing a seocnd one with the text saying "hoping it gets more attention than the competition" is pretty biased and provocative to the actions.
http://www.quasarcr.com/
The poster made a comment in the second bug saying that they hoped to get a faster response than on the MySQL bug.
The bug report link's in the summary, moron.
Ok, they fixed it. But did they actually fix it? MySQL is full of places where the developers didn't think about they were doing or cut corners.
Example: Let's say you want a column that auto-populates with the current time. In most databases, you would write a before insert trigger or have a column default of getdate(). A little extra work, but more flexibility and control. In MYSQL, you just use a timestamp column. What if you want two of them (say, inserted and updated)? Well, fuck you, MySQL can't do that.
is it appears the person assigned the bug only has one to work on (or I don't understand how the bug-zilla handles that).
"Don't meddle in the affairs of a patent dragon, for thou art tasty and good with ketchup." ~ohcrapitssteve
Has anyone checked with Oracle on the status of this?
I checked. They said they are waiting for the NSA to approve the code change.
Oracle, love'em or hate'em makes some rock solid databases. The reason for the delay in the patch release was most likely testing and validation of the patch. I am assuming Oracle does this for MySQL but, what do I know?
So what OP, want a cookie?
Indeed. This "bug" seems pretty stupid. I mean on the submitter's part. Why would any vendor spend much time solving this problem when it should be simple enough not to write such stupid SQL to begin with. Anyone who spent time working on this probably had nothing much better to do.
I mean really, I get it, but what is the use case for 'if a constant is equal to a different constant'?
For example, #1341. 10 fucking years old.
#68892 - best comment on the bug: 'Not quite sure how the severity scales are generally used, but shouldn't a trivial command that breaks the one feature that is being splatted all over the homepage as having significant improvements be a little higher than "non-critical" ?'
What about stupid shit like this: http://www.darkreading.com/database/expect-a-surge-in-breaches-following-mys/240001958?cid=nl_DR_daily_2012-06-14_html&elq=7e0510c44883432fa8e79c2ebde2ecb8 "The vulnerability itself is in the way MySQL accepts passwords -- the bug makes it such that there's a one in 256 chance that the wrong password will still grant the user access to an account. So an endless loop of attempts will eventually grant an attacker access. It was a bug so unique that Moore says some MySQL developers ran into it, couldn't reproduce it ,and eventually chalked it up as a fluke."
Is MySQL even ACID compliant yet, without addons?
http://nosql.mypopescu.com/post/1085685966/mysql-is-not-acid-compliant
Indeed. This "bug" seems pretty stupid. I mean on the submitter's part. Why would any vendor spend much time solving this problem when it should be simple enough not to write such stupid SQL to begin with. Anyone who spent time working on this probably had nothing much better to do.
I mean really, I get it, but what is the use case for 'if a constant is equal to a different constant'?
That's what I thought when the submitter said:
But when I comment out the 'M002649397' IS NULL OR clause (which has no effect on the result),
Yes, I guess technically this is a bug, but the obvious answer seems to be "Don't write stupid code in the first place". If you can take it out with no effect on the result, then why is it in there in the first place?
There is no such thing as a stupid bug. As for stupid posts that one is still up in the air.
"MySQL database's inbuilt functions like UNIX_TIMESTAMP() will return 0 after 03:14:07 UTC on 19 January 2038.[7]" from -> http://en.wikipedia.org/wiki/Year_2038_problem
* Just like 32-bit UNIX is - same 1970 UTC Clock "bug"...
(OR, it was one on UNIX variants @ least: Admittedly, not sure if those're fixed or not, or on what models/versions/vendors etc. - Like this one SHOULD or OUGHT to be for MySQL... afaik, it even happens in the 64-bit builds).
APK
P.S.=> That's one that definitely needs fixing... even if ONLY for the 64-bit (or better/larger memory addressing future builds)... apk
This is no surprise to anyone who makes Oracle support calls for a living.
Unless you bump up the severity to the highest level, you can expect months of wait and all-around handsitting.
READY.
PRINT ""+-0
Yea, I trust you on accurately reporting this.
Some may see this as a reason to use MariaDB instead of MySQL. Me, I see it as a reason to keep using DB2. Especially since Oracle can't tell the difference between an empty string and a NULL.
That's probably Larry's next step, to port that bit of brain-deadery to MySQL :-)
They said they are waiting for the NSA to approve the code change.
If anyone says they are acting under orders from the NSA, they are lying.
On the other hand, if they aren't saying that they are acting under orders from the NSA....
how many additional performance bugs the rapidly deployed Maria patch opens before we pass judgement. Speed without adequate QA is useless and self-defeating.
It's well known that the "Earth Momas" that regularly flock to RMS events and throw themselves at him, exchange flea communities with him, his "bush" is a variable "wild life park".
In fact, RMS makes his women sign a non-disclosure agreement prior to coitus.
I'm guessing if the SQL is generated programatically, you might get a constant = constant clause, although I'm having difficultly thinking of any sane situation where that would occur.
You are not alone. This is not normal. None of this is normal.
The optimizer is correct in making it run poorly, it is poor sql to begin with. If anything it should throw an error instead of accepting garbage.
If I saw you putting that in a project I would quickly fire you arse. Heck, I'd probably fire you for using mysql to begin with.
Oracle is trying to kill MySQL. It's sad - I loved it back in the day. Now not so much.
Do all the dedicated volunteers think their work won't be sold to Oracle? Also, they wouldn't want to break compatibility with this: http://www.oracle.com/technetwork/database/migration/mysql-093223.html
Dynamic query generation? The literal might actually be a variable on the client side - say, the contents of some optional string.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Yep.
select 1 from
table where
(? IS NULL OR foo = ?) and
(? IS NULL OR bar = ?) and
(? IS NULL OR baz = ?)
where foo, bar and baz are all optional.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
Yup, MariaDB is playing the same copyright assignment tricks that Monty used before, so that he could leverage community work yet still sell MySQL as a business. No reason to believe he's doing anything different this time. When the FSF asks for copyright assignment, that's acceptable because they have never breached the trust of their contributors. But when Monty does it, you have to assume he's setting things up so he can cash out again.
-- coalesce returns the first argument that is not null
select 1 from
table where
(coalesce(?, foo) = foo) and
(coalesce(?, bar) = bar) and
(coalesce(?, baz) = baz)
Clearly you haven't worked with many Indian developers before.
Its just failure to optimise a statement that nobody in their right mind would write. Like saying a compiler has a bug if it can't optimise away "if (1 != 2)".
MySQL bug is lodged with a priority of "S5" - pretty low.
MariaDB bug is "Major".
No shit one was fixed before the other.
This isn't a problem. Community will fork it again if something will go wrong. This matters.
How is MariaDB a small project and MySQL not? They both share roughly the same codebase and history. MariaDB has paid developers working on it, maybe even more than Oracle has on MySQL. For MariaDB, paying customers are probably more important than for Oracle, since Oracle can afford to lose money on this for a much longer time before they go bankrupt than MariaDB. If anything, the argument about "spending money on something only if it gives an immediate profit" applies way more to MariaDB than to Oracle.
I was promised a flying car. Where is my flying car?
Oracle has kept their testing suite and results closed source and secret. This is one of the reasons why MariaDB decided to do a cold hard fork and not look back. They can't possibly promise compatibility with Oracle since the specs are closed, effectively making the project closed. Assuming that Oracle tests things at all is purely speculation. If anything, regressions mentioned in other comments here suggest they don't do a very thorough job at all and their test suites only include new features and "old" tests, no regressions of bugs that got solved since they closed the testing specs.
I was promised a flying car. Where is my flying car?
The reason we have computers is to help us do complicated stuff. If you want the user to solve all the hard work, you're going to be searching hard to find the users that have the skills to use something. I believe it's the task of the computer (programmer) to make the most stupid users still get their results without breaking anything. It takes away "natural selection", sure, but that's what we humans have been doing since we exist as a species.
I was promised a flying car. Where is my flying car?
Why would Monty do it again? He's spending years of his life and a lot of his money to get MariaDB up and going. The risk he will be out of more money, not even counting his time than he'll ever get back is pretty high. For Oracle, MariaDB wouldn't be much of a purchase. They will have to painfully merge the difference in codebase, the developers and customers will all run away instantly and all they'll have left is the diffs. Any other company that wants an RDBMS will gain more from purchasing MariaDB than Oracle. So even if MariaDB gets sold, the most unlikely new owner would be Oracle.
I was promised a flying car. Where is my flying car?
Users are stupid, automated generators even more. You can't expect people to optimize queries themselves, which is why there is an optimizer in the code. If it brutally fails on something it is supposed to optimize, it's a bug.
I was promised a flying car. Where is my flying car?
If you're using MySQL or MariaDB then you're an idiot anyway.
And nobody is surprised that Maria is the same stinking pile the MySQL is.
The fix, as many said when Maria was released, is Postgres. It has been for years.
In fact the use of MySQL has become a litmus test for employment; if the company uses MySQL, I look elsewhere.
This demonstrates the difference between commercial/professionally run products and what can be a very ad hoc management style for open products.
A commercial organization receives a DR and reviews it. The DR is assigned a priority and a severity. Being obscure and performance related, I'd guess that it scored low on both. It doesn't impact security, it doesn't rear its ugly head often. So it won't impact many users, and presumably, the impact won't be that great. As such, and assuming that you have limited resources devoted to a product, it doesn't exactly float to the top of the heap.
But from the standpoint of code, the defect *might* be interesting! And in a looser environment, interesting trumps utility. Also, the impacted source might be more isolated... meaning to the volunteer "dive right in" developer, it is a more attractive problem to handle.
I'm not trying to defend Oracle or condemn the MariaDB team. I'm using this as an example of how different development processes and practices (highly managed/cathedral vs. open-uncommitted/bazaar) might yield different results. And how different group goals (further integration of MySQL into the Oracle family vs. ??? for MariaDB) might impact where efforts are place.
...it takes time to derive a method of generating revenue from a bug...
Loading...
Well, look at it properly, the bug is about optimization of a query that does not make much sense. Sure, it could be done better, but why would you issue such query at all.
If you look at problems that Oracle/MySQL engineering tackled, they are somewhat different - data compression, online DDL, parallel replication, GTIDs, InnoDB scalability, etc - these were huge efforts and get reasonable focus. Think of all the bugs that were not filed against MariaDB... :)
Count InnoDB engineers working for Oracle and for Maria, unfortunately that will not be balanced. Even Percona's InnoDB expert Yasufumi Kinoshita ended up working for Oracle lately.
Sure, Maria can do all sorts of tricks in SQL-land, but it is not the full picture. Oracle has much more engineering power dedicated to supporting MySQL, and they also have customers who are doing bug escalations as well.
Disclaimer: I used to work at MySQL AB and currently am working on a deployment that builds upon Oracle's MySQL tree, see https://www.facebook.com/MySQLatFacebook
Calling out a bug for comparing a quoted string to null, eg: '1234mhgt' = null tripping up the optimizer?
No wonder Oracle is ignoring their asses. I would too!
Hey KID! Yeah you, get the fuck off my lawn!
I too found an obscure bug (but in Sybase). Spent 2 months explaining it to their support. Repeatedly asked for a phone conversation (they simply ignored these requests). At the end gave up... It felt like talking to an idiot -- they just kept repeating some stupid phrases, and when I pointed out at problems in their logic -- never defend their position, just come up with another stupid argument. ;-)
So, folks, there are worse things that Oracle
I'm not even sure this is a bug. It's kind of like complaining that my C compiler didn't optimize out my infinite loop:
int main(int argc, char **argv) {
printf ("Die bastards\n");
while (1) ;
printf("Please die bastards\n");
exit (-1);
}
Whose problem is it?
A couple of years ago, I had a tech support call into Oracle for a Sun server. It took them almost a *month* to send out an FE, and that time included two weeks of emailing an engineer on another continent (S. America), and an "in country" engineer... who only worked third shift.
Oh, and after escalating it, three managers in three days "taking ownership".
I expect *everything* that Larry buys to be supported that way.
mark "wouldn't want to waste money that could be spent on his fighter jet or Hawaian Island...."
It took them several years to stop recognizing February 31st as a valid date. Don't expect quick bug fixes for something more than slightly harder.
"Solid Neutronium: There is no known way of blasting thru it..."
APK