Friday, 25 July 2008

Paris, City of Love and MySQL -- 19 September 2008

In an internal mail thread, I was asked whether there would be any "objections from an integration perspective" to some Sun initiated plans for a more organised French MySQL community.

My reply was that it's great, if it's something related to the self-organisation of the already very active French MySQL community (as witnessed for instance by the huge numbers that Véronique Loquet of Al'x Communication attracted to our Paris meetup in April). But if it's about a centrally-imposed structure of "marketing towards the user base", then I want to understand more and we need to discuss a bit further.

Based on the video link that Véronique sent me, it seems to be more of the former -- or if it's the latter, then they seem to have got it just right, for an event planned for 19 September 2008.

This is one of the best MySQL videos -- at least the funniest -- that I've seen so far!

As for the 19 Sep 2008 event, I hope I can make it, but it might be tough. Take a look at the video, and you know why (specifically why I hope to make it, not why it might be tough).

INSERT INTO plage (fille) VALUE ('mignonne');
DELETE FROM beaugosse WHERE cheveux LIKE 'Blond';
UPDATE geek SET serial = 'Lover';


  • plage = beach

  • fille = girl

  • mec = guy

  • mignonne = beautiful

  • beaugosse = handsome

  • cheveux = hair

  • moi = me

  • toi = you

La communauté MySQL se donne rdv;
le 19/09/2008;
à la cantine;
à partir de 18H;

Plus d'informations bientôt sur

Geek: Victor Rieunier;
fille: Mathilde Mallen;
Production: QNTV;
Réalisation: Morgan;
Musique: amsteroller;


Thursday, 24 July 2008

Ivan Nikitin: Contributions and Medical Status

Here's an update on Ivan's status, both from a medical and contributions perspective. Three days ago, I wrote that Ivan has arrived in Germany. Instead of posting all my news on Ivan as new posting each time, I will at irregular intervals keep this page up to date.

Andrii, Ivan and the rest of the family have now started settling in in Heidelberg. Georg Richter has found an apartment for them close to the hospital, and they will move there in a few days.

The first round of tests and examinations (blood tests, bone marrow punctation) has been concluded, but I won't share any speculations on this until we've got them confirmed. The examinations will continue, and the best case scenario is that a transplant could happen 8 - 10 weeks from now.

Currently donations for Ivan are at about EUR 90,000. Most of it comes from Sun Dolphins (former MySQLers) and to some extent from Sun Classic employees. And more than 25% represent donations from the MySQL Community! Thanks everyone! The German clinic expects at least an additional EUR 150,000 to be needed, though, so I encourge those of you who haven't contributed yet to press the "Donate" button at the end of the article on our official Ivan page.


Monday, 21 July 2008

Ivan Nikitin has arrived in Germany

Ivan NikitinAndrii Nikitin, his wife and their kids arrived in Germany today. Fellow MySQL Support Engineer Axel Schwenke gave them a ride from the airport to Heidelberg, where Ivan had his first medical checkup at the University Hospital.

Georg Richter has organised an apartment for the first days - until they get some furniture for the final one.

From what can be seen, they all do fine. About Ivan - that remains to be seen.

Footnote from our request to donate to help Andrii Nikitin's son Ivan:
Donations are requested to help Andrii Nikitin, a MySQL support engineer in Ukraine, provide for his son Ivan who requires a bone marrow transplant operation. The cost of this operation is expected to be between €150,000 - €250,000 ($235,000 - $400,000). Please help us provide Ivan a chance to live.

Yes, you can still help!


Federated Storage Engine: Disabled by default in MySQL 5.1.26, use with care

This blog entry is about a specific storage engine in MySQL. The Federated storage engine enables data to be accessed from a remote MySQL database on a local server without using replication or cluster technology. When using a Federated table, queries on the local server are automatically executed on the remote (federated) tables. No data is stored on the local tables.

When we released MySQL 5.1.24, the Federated engine was not compiled in, pending decisions on our future steps. The reason for the removal was that we realised (albeit quite late in the game) that Federated has some bugs that expose the server to unnecessary risks. Fixing these bugs is a time consuming process, because the root cause lies in the design of the Federated engine.

The removal was a safety precaution, which made the server more secure. However, it also deprived some users of an engine that they had been using for some time (Federated was introduced in MySQL 5.0.3).

Thus, we were left with the dilemma of more security versus more features. After much internal discussion, we reached a compromise. In 5.1.25, we reintroduced Federated as it was, but in the meantime we prepared a change for 5.1.26 which was just released. Federated is now compiled in, but disabled by default. This means that normal users won't be exposed to the possible side effects of using Federated tables. Users who require the Federated engine will be able to use it, by adding an option (--federated) to the mysqld command line or to the configuration file. Existing users of the Federated engine must be warned that using Federated can be risky, and it is not recommended for production.

We have a list of outstanding bugs affecting the Federated engine in our Bugs database.

Notice that the 5.0.x server is not affected by this decision. However, to allow security conscious users to disable Federated, we plan to introduce a similar configuration option in 5.0.66 and later releases.

We realise that the situation with Federated is undesirable. Therefore, we plan to replace Federated with a better designed, more robust engine, and we will welcome feedback about this task from the community and from our customers.

And as followers of MySQL Forge know (thanks Brian Aker for reminding me), there is already an initiative from the community, called FederatedX:
FederatedX Pluggable Storage Engine for MySQL is based off of the Federated Storage Engine, and is an attempt to moved the Federated Storage Engine forward to fix bugs, add new features and develop new concepts that are easier to achieve as a pluggable storage engine.

Thanks, Patrick Galbraith and Antony Curtis!

As for our general Federated plans: Please address your suggestions to community-contributions(at)


PostgreSQL: Goodbye Josh, welcome Peter

PostgreSQL logoI usually haven't been posting much about PostgreSQL even after joining Sun, so if I do, it must be something special.

And it is. Josh Berkus is leaving Sun, and Peter Eisentraut is joining.

Josh says:
After two years as Sun's PostgreSQL Lead, I'm leaving to pursue other opportunities. This does not mean that Sun is dropping PostgreSQL; far from it. Instead my fellow core team member Peter Eisentraut is taking over my role leading the PostgreSQL team at Sun. With Peter's experience in Oracle migrations and location near major Sun PostgreSQL customers, as well as many years leading the international team of translators for PostgreSQL documentation, he's going to do a great job with Sun's PostgreSQL development team. Probably better than me.

Peter says:
On July 22nd, 2008, I will be joining Sun Microsystems as PostgreSQL software engineer. Sun has been a valuable contributor to the PostgreSQL project for a number of years now, and I am looking forward to joining them in this effort. I am glad that I will be able to continue my personal role in the PostgreSQL project with the support of the great resources that Sun provides.

So, I expect that I will have more time to contribute to PostgreSQL development from now on, and both Sun and I have a sizeable backlog of projects and ideas that we would like to realize. Time to get started!

Over the years. I've met several times with both Josh and Peter. I'm sorry to see Josh go, but I have a feeling he won't disappear from the FOSS database circles -- so we'll meet again! And I'm happy to get to work closer with Peter, whom I've just met a couple of times at German or French FOSS database events. And I heard Peter is evening me out in the balance of people moving between Germany and Finland, so let's see where we'll see each other next.


Friday, 18 July 2008

MySQL 5.1 Use Case Competition

With 5.1 having officially been in Release Candidate status since September 2007 and soon approaching GA status, the MySQL Community Team launches a competition for the users of new features of MySQL 5.1:

Submit your MySQL 5.1 Use Case Report to community(at) by 31 August 2008 and have a chance of winning one of our prizes:

You may phrase your MySQL 5.1 Use Case Report freely, but the more colour you give it, the better your chances of winning.

By submitting the report, you also volunteer for appearing in our upcoming Use Case articles. We will consider any data you submit in your Use Case Report as public and quotable in our reports. However, you may ask us to anonymise certain aspects of your use case, should you otherwise not be able to participate in our competition.

This is the desired format of your submissions:
From: <you>
To: Community(at)
Cc: <any of your colleagues you wish to inform>
Subject: MySQL 5.1 Use Case Report: <Feature> / <App Name>

MySQL Community Team,

At <company/organisation> we've used <new 5.1 feature> since <date>.

We're now on MySQL 5.1.<n> and we started development using
<new 5.1 feature> with MySQL.5.1.<m>.

Purpose of our appication:

Reason we need <new 5.1 feature>:

Development environment, OS, language:

Deployment environment, OS, hardware:

Relevant metrics on size/type of application:

Our comment on how <new 5.1 feature> meets our needs:
- comments on usability of feature
- comments on clarity of documentation
- comments on performance
- comments on bugs encountered [1]

Our greetings to the MySQL Engineering Team:

Name and email of submitter / developer:

Name of organisation:

Geographic location (city, country):

MySQL Enterprise customer: (YES/NO)

[1] If you've found bugs, then please follow our bug reporting instructions and share bug numbers from in your use case report.

We're looking for Use Cases on all new MySQL 5.1 features, but especially on