Comments on: MySQL and plugin binaries http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/ Everything about MySQL Performance Sat, 21 Nov 2009 05:23:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: peter http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/comment-page-1/#comment-284568 peter Mon, 21 Apr 2008 18:15:26 +0000 http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/#comment-284568 Vadim, In the perfect world it would be great to have SE Interface version which is same for Major MySQL version - say 5.1 6.0 etc. But with the way things are right now I'm not expecting it to handle any time soon. So the question should be what can be done to ease the pain on Storage Engine Vendors (which kind of includes us with Sphinx Storage Engines) and avoid surprises as Innodb got with their plugin release. I think what would be important is to involve vendors in QA process. Innodb should have working with MySQL to ensure their plugin at least builts with MySQL 5.1.24 (I'm not speaking about binary compatibility) For community storage engines such as PBXT process some kind of similar to Linux Kernel could be established - Community is to provide their storage engine to MySQL so it can be built ant minimally tested with new version release. If it breaks - Community should get an alert about it to be able to fix things quickly. Similar process can be employed with Commercial storage engine vendors but in more formal fashion. Vadim,

In the perfect world it would be great to have SE Interface version which is same for Major MySQL version – say 5.1 6.0 etc. But with the way things are right now I’m not expecting it to handle any time soon.

So the question should be what can be done to ease the pain on Storage Engine Vendors (which kind of includes us with Sphinx Storage Engines) and avoid surprises as Innodb got with their plugin release.

I think what would be important is to involve vendors in QA process. Innodb should have working with MySQL to ensure their plugin at least builts with MySQL 5.1.24 (I’m not speaking about binary compatibility)

For community storage engines such as PBXT process some kind of similar to Linux Kernel could be established – Community is to provide their storage engine to MySQL so it can be built ant minimally tested with new version release. If it breaks – Community should get an alert about it to be able to fix things quickly.

Similar process can be employed with Commercial storage engine vendors but in more formal fashion.

]]> By: Vadim http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/comment-page-1/#comment-284478 Vadim Mon, 21 Apr 2008 14:44:49 +0000 http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/#comment-284478 Jay, Yes, that probably is OK if plugin API is not changed a lot in incompatible way. Jay,

Yes, that probably is OK if plugin API is not changed a lot in incompatible way.

]]> By: Vadim http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/comment-page-1/#comment-284475 Vadim Mon, 21 Apr 2008 14:39:20 +0000 http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/#comment-284475 Giuseppe, Sure, I know building process of MySQL and that's why I said it was not intentional. Giuseppe,

Sure, I know building process of MySQL and that’s why I said it was not intentional.

]]> By: Jay Pipes http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/comment-page-1/#comment-284405 Jay Pipes Mon, 21 Apr 2008 13:04:24 +0000 http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/#comment-284405 Giuseppe, Vadim, I think the solution is to have a MYSQL_PLUGIN_API_VERSION (or MYSQL_PLUGIN_SE_API_VERSION for storage engines, for example) which does not depend on the MYSQL_SERVER_VERSION... seems simple enough to me. -jay Giuseppe, Vadim,

I think the solution is to have a MYSQL_PLUGIN_API_VERSION (or MYSQL_PLUGIN_SE_API_VERSION for storage engines, for example) which does not depend on the MYSQL_SERVER_VERSION… seems simple enough to me.

-jay

]]> By: Giuseppe Maxia http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/comment-page-1/#comment-284276 Giuseppe Maxia Mon, 21 Apr 2008 08:40:24 +0000 http://www.mysqlperformanceblog.com/2008/04/20/mysql-and-plugin-binaries/#comment-284276 "It was very charming move from MySQL side to release new incompatible binary on the second day after the announce of InnoDB plugin." Vadim, you have worked at MySQL for quite a long time, and so you must know that a build is not instantaneous, but takes several days, possibly weeks, as it involves building and executing extended test suites on all the platforms supported by MySQL. The tagging of MySQL 5.1.24rc and subsequent builds were planned and executed long before the InnoDB announcement. The conspiracy theory is groundless. You may argue that the plugin interface is tightly coupled with the server version, and it's true. It's the same problem that you face when using PBXT plugins, for example. If you know how to fix this problem, feel free to contribute the solution. (http://forge.mysql.com/contribute/) Best regards Giuseppe “It was very charming move from MySQL side to release new incompatible binary on the second day after the announce of InnoDB plugin.”

Vadim,

you have worked at MySQL for quite a long time, and so you must know that a build is not instantaneous, but takes several days, possibly weeks, as it involves building and executing extended test suites on all the platforms supported by MySQL. The tagging of MySQL 5.1.24rc and subsequent builds were planned and executed long before the InnoDB announcement.
The conspiracy theory is groundless.
You may argue that the plugin interface is tightly coupled with the server version, and it’s true. It’s the same problem that you face when using PBXT plugins, for example.
If you know how to fix this problem, feel free to contribute the solution. (http://forge.mysql.com/contribute/)

Best regards

Giuseppe

]]>