Hacker News new | comments | show | ask | jobs | submit login
An open MySQL bug receives a real Birthday cake (mysql.com)
406 points by ted_turner 1364 days ago | hide | past | web | 78 comments | favorite



I think gittip is great, and I understand this is the opposite of their philosophy, but I want a well-used bounty program for these things.

I mentioned some Django bugs that are huge for us that were finally fixed in 1.6 in another thread [1]. I'd have personally pledged a couple hundred dollars to have them fixed, and probably could have gotten considerably more pledged from my company. Does this tool/platform exist and I just don't know about it?

[1] https://news.ycombinator.com/item?id=5958281

[Edit]

Thanks for the replies. Pledgie and bountysource look interesting and I suppose really close to what I was imagining, in spirit. Fundamentally, I'd like to see something well-executed help formalize the process behind what motivated Andrew's awesome Django migrations kickstarter [2]. I really like the way that came together because it had the buy-in of the team, and there-by inspired confidence in potential backers.

[2] http://www.kickstarter.com/projects/andrewgodwin/schema-migr...


http://freedomsponsors.org is a crowdfunding platform for Open Source projects.

This is how it works:

1) Someone places a bounty for a problem (tipically an issue registered on an issue tracker)

2) More people might want to sponsor the same issue

3) A developer solves the issue

4) The sponsors verify the solution and pay the developer

The FreedomSponsors website itself is an open source web application, written in Django. Funny fact - some of its own issues have been sponsored in the website.

The source code - along with instructions on how to run it - can be found on Github. https://github.com/freedomsponsors/www.freedomsponsors.org


Hi Tony! Sorry, getting to this late. freedomsponsers.org looks totally in line with what I was imagining. I presume you built it, so thanks! I hope it gets traction.

[Totally unsolicited... I'd vote to change it's name. I know it seems silly/shallow but I thought of a million and a half things that it might be before I clicked he link, and none of them were even close to what it is. (Mostly I would have assumed it to be a Koch Brothers fundraising organization)]


I'm not convinced Oracle (ORCL), listed on both the S&P-500 and the NASDAQ-100, needs or will accept bug fixing donations, especially since MySQL is a competitor to their flagship Oracle DB and there was quite a lot of disgruntlement around the acquisition. Maybe if you gave money to MariaDB it would work.


Agreed, fuck 'em (not that you were saying that, but I am). My point was I want something like this for projects and bugs I care about in general. I don't care about this bug, but can relate to the cake-maker.

To anyone not yet familiar, Maria is a really exciting fork of MySQL - https://mariadb.org/


Do you have some info about MariaDB adoption rates?


It's recently replaced mysql in redhat builds, so it's definitely on the up.


    > It's recently replaced mysql in redhat builds, so it's definitely on the up.
"Red Hat's Director of Product Marketing, Mark Coggin, told various media outlets that the company has not made any decision or made an announcement about which database technology will be in Red Hat Enterprise Linux 7."

-- "Red Hat Says No MariaDB/MySQL Decision Made." The H Online, 18 June 2013 (http://www.h-online.com/open/news/item/Red-Hat-says-no-Maria...)


And in OpenSuse, Arch and Slakware. Looks like to me the trend is set.


Oracle might not accept bug fixing donations. But it should accept bug fixing patches from an independent developer. And that developer might accept a bug fixing donation.

That's where a service like http://freedomsponsors.org comes in handy ;-)


> MySQL is a competitor to their flagship Oracle DB

Does it really? I mean, sure, they are both RDBMS's, but that's a pretty broad market. Are there really that many use cases where, with the current market, people who are using MySQL would have Oracle as their next choice or vice versa?

I can see an argument that MySQL competes with some of the same products that Oracle DB competes with (but in different market segments than where Oracle DB does), but I don't see them as directly competitive in any significant sense.


To me, that's kind-of like saying the MacBook Air is a competitor to Apple's flagship MacBook Pro. They're two different products, made by the same company, doing pretty much the same thing but designed for different use cases. It's the way I always felt about Oracle vs. MySQL, even back before Oracle owned MySQL, that they are two different RDBMS platforms designed for two different use cases.

These days, that line may be blurred a little bit, and you can see how both paradigms (and more!) can be combined into a single product with PostgreSQL, but I feel like the MacBook analogy really sums up the way I feel about these two systems.


My project is in that position. We have access to an Oracle site license so we use it. However, we're considering move to a "competing" db, probably postgresql or mysql.

I'm not a certified DBA so take this with a grain of salt, but it seems that any non-trivial use of Oracle systems ramp up in cost very quickly. Both in terms of hard cash and time in education/training.


> We have access to an Oracle site license so we use it. However, we're considering move to a "competing" db, probably postgresql or mysql.

Good point; I was considering mostly the situation where there isn't something already on hand, but it makes sense that there would be quite a lot of times where MySQL and Oracle DB are considered alternatives for a new project/application by shops who already have an existing installation of one or the other.


Given there are more engineers working on MySQL now than any time in its history, I think Oracle is pretty committed to it. MySQL is about fast, OracleDB is about enterprise. A great many companies will run MySQL for things like web applications (especially those that need scale) while running the critical internal systems on OracleDB.

I don't think the MBPro/MBAir comparison is quite right. I think it's more like MBAir versus Mac Pro: it is very easy to see a single person having both of them and utilizing both of them extensively.


> Are there really that many use cases where, with the current market, people who are using MySQL would have Oracle as their next choice or vice versa?

RDS users?


Fortunately, lots of people other than Oracle work on the MySQL code. They would be susceptible to bug fixing donations. Hell, you could outright hire a Percona consultant.


Is this what you're thinking of? https://www.bountysource.com/


Nice. I signed up, but it doesn't look like there's much listed. Also, there doesn't seem to be a way to search for bounties to work on?!


Open bounties are listed on the project pages: https://www.bountysource.com/#trackers/48759-jshint



There are companies which you can pay to produce mysql fixes you specify. One of which is Percona. Won't be as cheap as gittip or something similar, but you'll get the results without relying on a bug hitting the top of someone elses' priority list.


So Percona is able to create a customized fork of MySQL for you? won't that create a maintenance problem in the future? I mean, you won't be able to get official update releases anymore.


Percona already runs their own MySQL fork. (http://www.percona.com/software/percona-server) They include various patches that their customers have asked for and also update it every time Oracle releases a new MySQL version.


Would be cool if you could submit an automated test and your bounty was automatically awarded as soon as the test passes.


A little risky though, if your test is imperfect. People may work to outsmart the tests rather than actually solve the bugs.


Yes, I was going to add a note on that but then I realized this problem (people cheating) would exist anyways as long as there isn't a trusted third party to handle conflicts. I don't think this would be a common issue though as most open source developers are not driven by the money and I don't think there would be enough money to attract scammers (would someone really get into the trouble of writing an open source software hoping to one day cheat people out of their money when they submit bug bounties?).


You can try FreedomSponsors - http://www.freedomsponsors.org/


Have you tried (politely) emailing a core dev? That could work.


You mean sending a polite email offering a couple hundred dollars to fix a bug? I haven't. In addition to seeming tacky, I think the idea behind a bounty system is that it provides a way to crowd-source the effort and I wonder if having more demonstrated skin in the game around key issues might help reduce bike-shedding, or better convey the tangible value an issue has to users.


It's interesting that you mention a feeling of "tackiness" with respect to directly funding something via a bounty system. Although my personal project [1] isn't necessarily about providing incentives to open source software development, I did recently launch a new subsection focused on motivating businesses to act out of a motive other than the profit motive alone.

The motivational approach I took was slightly different than crowdfunding. Instead of directly funding the tasks you want to see completed, the bounties are donations to charity made on behalf of the tasks. They can be either made immediately to establish your level of seriousness or made when the task completes, to provide ongoing motivation.

Since I am focused primarily on motivating city governments and businesses, I felt the same way as you: direct funding is not the right thing to do. These governments and businesses already have funds. If I want to sway their decision-making processes in some unusual way, my experiment is using public charitable donations.

Just as a demonstration, I just created a task for this (admittedly, not really what I have in mind for my site, but I'll take whatever eyeballs I can get) [2].

[1] https://www.brianstaskforce.com/

[2] https://business.brianstaskforce.com/task/385/oracle-address...


That's really cool! To be clear though, I felt it tacky to pick a core dev and email them directly as opposed to making a more public and transparent commitment in some other forum.

Still, I like your project quite a bit. Looks very nicely executed.


That makes sense. Thank you for the kind words, they are really appreciated!


Yes, that's what I meant. Why is it tacky? Sure, if there were a public "official" way to do so, it'd be preferable, but if you really need a Django bug fixed ASAP, there's nothing wrong with sending a nice email to a django core dev saying "Would you be open to fixing it soon, and we'll pay you $X?".

Open source developers don't bite, and they never say no to a bit of extra cash :)


Wait! Read "Drive" first. Open Source is a textbook example of people working for intrinsic motivation. While offering money might make that bug get fixed sooner, it very often reduces their drive to work on the open source project in the long run.


I can definitely see it having a negative effect. I don't do bounties anymore. It was too easy to get ripped off. They're basically a freelance gig with no guarantee of getting paid and no deposit to protect you when the person disappears after the work is done.

Thing is I likely would have done the work anyway. Bugs are community issues that effect everyone and contributing fixes for them keeps an open source project vibrant and active. But instead of feeling good about fixing some obscure bug I felt like I'd been used by someone who didn't want to pay for a developer.


Still feels icky to me. I'd rather this stuff be public and done in a way that the community and the rest of the core team know what's going on. I'd worry that backdoor payments done this way would negatively affect the spirit of how these projects are run.


Actually there are some OS devs who bark quite rudely that can be as bad as getting bitten.


The video bringing cake and ice cream to this bug's 7th birthday:

http://www.youtube.com/watch?v=oAiVsbXVP6k

It's got a real Joker laugh going on toward the end.


so I see 301+ views on the video and had to go get the obligatory xkcd http://www.xkcd.com/1224/

Also, I wonder why he chose to record it in his bathroom. Those are definitely shower curtains and the echo is definitely bathroom-esque. Maybe for acoustics.


I cried a little on the inside when I saw the proposed C regexp 'solution'.


The conventional workaround:

  $ mysqldump -d my_database | sed 's/ AUTO_INCREMENT=[0-9]*\b//' > dump.sql


That's also listed in the comments for the bug, as well as some (contrived) examples as to when it wouldn't work. Surprising it hasn't been fixed, considering how simple the true fix is.


Using compressed air to blow out the candles was a nice touch.


Until you get a can of cheap imported "air duster" air which contains propane propellant still and instantly results in a firey ball of death...

Only posting this because I've done that before :)


That's still nicer than the thermal decomposition products of fluoroethanes.


I was curious about your comment so I did a few searches, and it looks like a major decomposition product is hydrogen fluoride.

According to Wikipedia: "Hydrogen fluoride is a highly dangerous gas, forming corrosive and penetrating hydrofluoric acid upon contact with tissue. The gas can also cause blindness by rapid destruction of the corneas."


IIRC the components of "air duster" are heavier than air (they settle in the bottom of the lungs and are hard to exhale) while also a trigger of cardiac issues. I wouldn't want to inhale the uncombusted gas!


I have a rudimentary knowledge of MySQL Internals, so I am going to take a guess why it has taken so long.

They want to implement this feature server side, which means that they either have to add: (1) A new server setting (SET SHOW_CREATE_TABLE_FORMAT = Blah) -or- (2) New syntax (SHOW CREATE TABLE NOAUTOINC mytable).

Adding new settings is always evil, and adds to product confusion/complexity.

Adding new syntax is a bit evil in MySQL's case since they use a generic yacc parser, and might have to add a new reserved word (truthfully, I'm not 100% sure on that one). There is also a preference to only add reserved words to major new versions.


Of all of the things I've done in technology, this was not near the top of the list of things that I thought would be on the top of hacker news (no, I didn't do the cake, just filed the bug 7 years ago).


Today is my actual birthday, me and bug #20786 should share that delicious cake and ice cream.


And, cross-commenting from the Tau Manifesto post, "tau" means "for you" in lithuanian, so go ahead and have a delicious slice of HN homepage for your birthday.


For those unclear of the reasons this is bad (aside from the assumption that the pure raw data structure should not have any artifacts of custom data definition) - it is probably something in code or, more likely, initialisation data, that is expecing the Id to be something. This may be a file of SQL inserts that is run after the database is created, with hardcoded primary keys. This is an antipattern of course, but it doesn't excuse the fact that pure structure dumps should remain as such. (disclaimer - I have little experience with mysql, but have seen these same antipatterns in SQL server, oracle, and db2 data init scripts far too often).


Personally, it's the guy's laughing that does it for me.

What does this bug cause?


`mysqldump` is a utility included with MySQL to dump a copy of tables and their data to a text file of SQL queries. Tables may contain a column with the AUTO_INCREMENT property where values in that column are generated from a sequence (i.e. 1, 2, 3, 4, 5).

The bug requests that the table definition written to the dump file by this utility not contain the current value of the AUTO_INCREMENT sequence when the option to dump only definitions, not data, is used.


It pack the autoincrement value inside the create table statement generated by mysqldump even if you use the --no-data option.


If any MySQL bug needs a cake it's this whopper I just ran into: http://bugs.mysql.com/bug.php?id=1341


That's pretty silly, as any serious installation is generally using innodb_file_per_table, and thus not really subject to this problem.

Nonetheless, it's a lot more complicated than it would seem to "just reclaim the space".


I disagree that any serious installation is using innodb_file_per_table. It does have downsides.

In our use case we're making very heavy usage of table partitioning (over 500 partitions for some of our very large tables). Because each partition is effectively another table under the covers, if we were to use innodb_file_per_table then we'd have tens of thousands of files. This means a lot more file handles being opened/closed (as well as the obvious ulimit gotchas for the uninitiated). This noticeably hampered query performance when seeking data from random partitions.


I've managed many non-trivial MySQL installations that didn't set file_per_table. I agree it is a step towards fixing the problem but can create potentially other issues.

Current shop is not running file_per_table, and has little reason to do so at ~30GB database file size. Still, dropping the table and not reclaiming any space was a rude awakening. Combine that the fact that storage was an AWS EBS sized pretty close to its limit (50GB). I could not perform two iterations of a test import without first rm'img the file. Lame.


Sadly MySQL has a history of bugs like this. There are a few we have run across that have probably been open longer than this bug, and yet have not been fixed. I'd have to look the bug numbers up from e-mail, but yeah.. there are tons of mines out there in MySQL just waiting for you to hit them, and upon further discovery, someone else found out about it years ago!


I've had many experiences like this as well. Even some of our paid for software gets scared if you use a buggy MySQL version (TeamCity for example refuses to start on certain MySQL versions).

Switched to postgresql now - just works!


But until you get to the point that "just works" it's a huge pain in the behind (configuring, etc)

Also, the SQL syntax is usually a pain to get it first (MySQL is much more tolerant for a newcomer)

And yes, PSQL commands usually work in MySQL (except for the specific stuff, like \dt but that's not even SQL so...)


Seriously?

I find it much easier from an admin and dev perspective. It is less forgiving, that is correct, but that's a good thing. Oh and the documentation is wonderful compared to MySQL.

Plus it works properly.


I was just reading this article; you might be interested:

http://grimoire.ca/mysql/choose-something-else


shrug Everyone hates on MySQL, and I have my periods of hate as well (mostly I think they boil down to actually hating the Developers of MySQL, not the actual software)... But the thing is that for our purposes MySQL works and works well 99.9% of the time. Additionally the actual big, real issues/beefs people have with MySQL are mostly fixed in 5.6 (multi-threaded slaves (really guys, you should have fixed that years ago), online ALTER TABLE (again... wtf, why was that not fixed years ago)).

He also is hating on PHP in that article, which seems like prime HN bait, because as it does every time there is a PHP hate article on here, everyone actually doing real work comes and and says 'Okay, have fun with your rubies and nodes'.

With all that said, recently a lot of our data has started to be organized outside of MySQL (a lot more Couchbase and Solr usage), but MySQL is still there driving the core data. I'd say it all boils down to right tool for the job.


Well, I just took 10 minutes to write an ad-hoc parser that will probably fix the bug (it works around the tricky test cases in the thread)[1]. I don't really understand why they want to move stuff onto the server-side, there may be some other trickery I'm missing.

Please feel free to use as-is and integrate it into mysqldump. I can't be bothered to create an account on bugs.mysql.com.

--

[1] http://pastie.org/8092330 (EDIT: The parser wasn't fully correct, use [2])

[2] http://pastie.org/8092403


While I agree it has potential to be annoying in some environments, it's also trivially simple to work around.

    for tbl in $(mysql -BNe "SELECT DISTINCT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE EXTRA = 'auto_increment' AND TABLE_SCHEMA = 'mydb'"); do
      mysql -e "ALTER TABLE ${tbl} AUTO_INCREMENT=1" mydb
    done
Run that just after importing your new schema.

Note: That code will require a bit of modification if you make the mistake of having spaces in your table name.


I store the dump of the database in source control, so several years ago I made a small program mysqldump_ddl to strip out all ephemeral data that clutters up the changes:

    #!/bin/sh
    mysqldump --no-data $* | sed 's/ AUTO_INCREMENT=[0-9]*//' | egrep -v '^-- (MySQL dump|Server version|Dump completed on)'
Now the database diff only has actual changes. (Mostly - sometimes new versions of mysql change other things.)


I don't believe in autoincrement so I'm not up to date on the evil things you can do with it, so I'm unclear why this bug matters: All it does is change the arbitrarily chosen start value for new rows, what could that break?

The existing behavior makes more sense anyway, as it preserves 'truncate table' <=> 'restore nodata dump' equivalence better.


That is also a way to solve it: make it a documented change. But it looks like it was completely ignored. So happy birthday!


It's less that it would break anything and more that it's philosophically wrong to be outputting what's basically a historical max value field when asked not to output data.


Here is the cake: http://youtu.be/oAiVsbXVP6k


The speed at which they get regexps out is kind of frightening, I find...


I just had occasion to use mysqldump --no-data a few days ago, and then came across this today. Not a good feeling! C'mon, mySQL devs ... fix it already.


Is this bug still present in the MariaDB fork?


Yep, I've been hit by that bug numerous times over the years. Sed works fine for editing the dumps. Happy Birthday!


Damnit, now I want cake and ice cream!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: