Xaprb

Stay curious!

What happened to Falcon?

with 17 comments

I don’t think I have heard anything from the Falcon team for a while. What’s new? Did the project really stall when Jim Starkey left, as Vadim Tkachenko wondered might happen?

Written by Xaprb

September 23rd, 2008 at 8:15 pm

Posted in SQL

Tagged with , ,

«
»

17 Responses to 'What happened to Falcon?'

Subscribe to comments with RSS

  1. I’d also like to know the answer to this. It certainly appears that MySQL folks have been deemphasizing Falcon — or at the very least, not emphasizing it as much. I did see Brian Aker’s recent drizzle slides mentioning future engines including PBXT and Maria, Falcon’s absence from that list seems conspicuous but not sure how much we should read into that.

    Despite what they say in public I can’t imagine Sun/MySQL is *really* satisfied with their premiere engine being controlled by a 3rd party. This is especially the case since InnoDB seems to be pushing themselves to a plugin route which implies they may want their own support contracts in the future.

    Interesting times…

    Ryan Thiessen

    23 Sep 08 at 8:56 pm

  2. I think the development is going on – I see my bug reports is being slow fixed. Not sure about speed though. It was said there are three more developers instead of Jim Starkey to continue work on Falcon

    Vadim Tkachenko

    23 Sep 08 at 10:12 pm

  3. But actually I think without main creator and architect the project will not have success. So it would be better for Sun to sell it to Microsoft or Oracle :)

    Vadim Tkachenko

    23 Sep 08 at 10:17 pm

  4. According to this post, Jim is still active on Falcon. https://slashdot.org/comments.pl?sid=954987&cid=24895289

    Toby

    23 Sep 08 at 11:11 pm

  5. Falcon is alive. The marketing for it has been quiet but the developers have been busy. They fixed all of my bugs so we can begin perf testing when the 6.0.8 release is ready.

    Mark Callaghan

    24 Sep 08 at 1:15 am

  6. The Falcon team fixed quite some bugs these months and we are waiting for our 6.0.8 release.

    The impatient can try our mysql-6.0-falcon tree at launchpad, which I try to keep up to date:

    https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-falcon

    Hakan Küçükyılmaz

    24 Sep 08 at 1:15 pm

  7. Falcon is chugging away. Kevin is doing a fine job as team lead. I’m still involved (albeit in a diminished role) as backstop. I’m just back from the MySQL engineering meeting in Riga where I spent a week working with the Falcon guys.

    Functionality is now 100% complete for the 6.0 release. The team is now focused on stability (a euphanism for “no bugs”). Performance is good, particularly with a larger number of cores, but this is not to stay that Kevin and the crew are done with performance. The nature of the current crop of outstanding bugs is mostly SMP cache coherency problems on non-locked shared data structures. Those of you with experience with non-interlocked data structures will recognize how hard these are to shake out. People without experience on high performance, transactional, multi-core programming tend to underestimate the difficulty. Hell, so do those of us with experience.

    Falcon is the only general purpose transactional storage engine that MySQL controls. InnoDB, you are aware, is owned by Oracle, and Monty punted on making Maria transactional. Making a transactional database engine isn’t exactly easy. Making one transactional, high performance, on modern many-core architectures is difficult and requires time to resolve issues.

    Yes, if Falcon were on schedule, MySQL 6.0 would have shipped two years before 5.1 (my, wouldn’t that have shaken everyone up). The reality is that Falcon was conceived, acquired, staffed, and integrated between the original 5.1 GA date and the present. Being a little late is a time honored MySQL (and just about everywhere else) tradition. Falcon is just following the footsteps of giants.

    Brian’s position on Drizzle is that he’s only taking GA-able code, and Falcon ain’t there yet. And, not incidentally, neither is Maria.

    (Standard disclaimer: I don’t speak for anyone but myself, yada yada yada.)

    Jim Starkey

    24 Sep 08 at 2:12 pm

  8. @Jim

    Does crash recovery work on Falcon? I assume yes given that it is functionally complete.

    When did Monty punt on supporting transactions?

    Mark Callaghan

    24 Sep 08 at 3:15 pm

  9. Is crash recovery 100% reliable? Nope. We’ve recently learned how to generate non-recoverable crashes. This is good news. Reproducable bugs are a lot easier to fix.

    Functionality complete does not mean bug free. If it did, there would be very few functionality complete products on the market. I’m of the school that believes that “bug free” is a synonym for “inadequately tested”.

    I don’t know when Monty punted on transaction support. It’s been a non-goal for at least a year. Maria is now defined as crash-resistent MyISAM. I’m sure they’ll have recovery bugs and I’m sure they’ll fix ‘em, too.

    But speaking of feature complete, why doesn’t Chrome have the Google Tool Bar? I like Chrome, but can’t live without the tool bar. It’s bad enough having Falcon and Maria at odds, but having two part of Google at war is just intolerable! Let’s get with the program, gentlemen (note the subtle deflection of focus here).

    Wasn’t Riga a pretty city?

    Jim Starkey

    24 Sep 08 at 3:33 pm

  10. I was under the impression that crash recovery didn’t work most of the time. From your description, it doesn’t work some of the time.

    Maria 1.5 is to be crash safe. Maria 2.0 is to do full blown transactions. See http://monty-says.blogspot.com/2008/01/maria-engine-is-released.html or ask Monty.

    Mark Callaghan

    24 Sep 08 at 3:43 pm

  11. I was wrong about crash recovery in Falcon. I look forward to testing 6.0.8. Performance for CPU bound loads was pretty good in 6.0.5, so 6.0.8 should be better.

    Mark Callaghan

    24 Sep 08 at 4:33 pm

  12. I’m afraid your impression was wrong. Up until a new stress testing system came online, it was passing all recovery tests. The bug appears to be an error in computing the recovery point in the serial log. It’s a bug and will get fixed.

    Jim Starkey

    24 Sep 08 at 4:39 pm

  13. We stress test our replication tests by frequently killing a slave during replication. If replication in MySQL were bulletproof, then that would be a great test for Falcon because you can compare the contents of the slave with the master after the test is done and you know that anything done on the master must be done on the slave despite the restarts.

    Alas, you need transactional replication from the Google patch to be implemented for Falcon and a few more bugs to be fixed in the handling of relay-log.info for this test to run for any amount of time.

    Mark Callaghan

    24 Sep 08 at 4:44 pm

  14. Falcon development is quite active. Just check our commit messages at launchpad:

    https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-falcon

    Hakan Küçükyılmaz

    24 Sep 08 at 4:50 pm

  15. Glad to hear of the progress! Jim, I hear Riga is a nice city ;-)

    Xaprb

    24 Sep 08 at 5:08 pm

  16. [...] of jobs, Baron Schwartz of Xaprb is wondering, What happened to Falcon? in the wake of its daddy Jim Starkey leaving his job at Sun/MySQL. The item is a call for news, [...]

    Log Buffer #116: A Carnival of the Vanities for DBAs

    26 Sep 08 at 12:52 pm

  17. [...] All organizations have comings and goings. Some of the departures are exaggerated; for example Jim Starkey hasn’t totally left us. Others won’t affect development because the departers haven’t been contributing to the [...]

    MySQL :: New Features In MySQL 6.x

    12 Oct 08 at 2:34 pm

Leave a Reply