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."

Comments

We need more data

[WWJohnBrowningDo]

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?

Re:We need more data

[Darinbob]

A sample size of one is insufficient to make any meaningful conclusions.

That sort of thinking won't get you very far in politics.

Re:A Post with an Agenda

[NoNonAlphaCharsHere]

Well, DONTGIVEAFUCK is one of the statuses on their Bugzilla. Just sayin'.

This is surprising why?

[PhrostyMcByte]

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.

Well...

[Ramirozz]

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.

Not really a fair test

[greenreaper]

The poster made a comment in the second bug saying that they hoped to get a faster response than on the MySQL bug.

Re:who cares?

[Daniel Dvorkin]

mysql is of historical curiosity. At best.

I'd be willing to bet there are more deployments of MySQL than of all other standalone RDBMSs combined.

Re:who cares?

[MightyMartian]

Because we all know that's how you tell that something's better.

I'm taking my Betamax tapes and going home! And get off my lawn!

What about 10 year old mysql bugs?

[the_B0fh]

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

Re:What about 10 year old mysql bugs?

[greg1104]

I don't think it's possible for MySQL to get the "C" part in ACID right without a total rewrite, which seems unlikely under Oracle's watch. There used to be all sorts of trivial ways you could insert garbage data into MySQL, things like February 31 being a valid date or numbers going into boolean fields. They added this strict mode as a way to add validation for most of that. But strict is a client setting. All it takes is one client that ignores this, and the engine will still let you put garbage into there--values that are not going to be valid if you later work on them using a strict setting client. If you can put data in one end of that's not correct when read by another client, that's the exact opposite of a "consistent" database. It boggles my mind that anyone finds this acceptable. I guess people who do all their validation on the client are fine with it maybe? I can't explain how people who don't understand databases at all make their decisions.

I don't follow MySQL closely enough to know if they're still silently truncating data sometimes too, but that's been a nagging problem over the years too. Strong validation of data is like security: you don't just bolt it on later. It's something that needs to be enforced in as many places as possible in the code, if you want any hope of getting it right and bug free. If you actually want data to be validated in all situations, you need to use something like PostgreSQL instead. There even new types you add to the database can execute any check constraint function you want before that data is allowed in, period. That overhead contributes to why MySQL is faster on trivial things, but sometimes you get what you pay for.

Re:who cares?

[cold fjord]

Some people never learn until you throw a laser disc at them. It smarts enough that they normally don't want a repeat.

Re:who cares?

[Literaphile]

No, but it is how you tell whether something is "of historical curiosity", which obviously MySQL is not, since it's the most popular RDBMS by far.

Re:who cares?

[marcello_dl]

The confusion arising from the fact that oracle mysql shares the same name with the former mysql, while mariadb which is philosophically the natural heir of the latter had to choose a different name.

Apparently Oracle did the right thing by buying up the name, many fall for it and many others mod them up. Depressing, huh.
And now you all proper slashdotters are thanking God that something named "postgresql" has basically no marketing value, aren't you.