[Libdbi-drivers-devel] Bug with mysql driver with errors from timeouts from mysql
I've started working with transactions in mysql and I believe I've run across a bug in libdbi's mysql driver. When you get a lock timeout on a select, it is reported by mysql by returning a null from mysql_store_result. This currently isn't noticed by the driver. In dbd_query (and dbd_query_null) in dbd_mysql.c there should be 3 cases: mysql_store_result() != null good select mysql_store_result() = null mysql_field_count() = 0 good insert ... mysql_store_result() = null mysql_field_count() 0 error on select I'm not sure if a patch would be as simple as: --- res = mysql_store_result((MYSQL *)conn-connection); + if(!res !mysql_field_count((MYSQL *)conn-connection)) + return NULL; /* if res is null, the query was something that doesn't return rows (like an INSERT) */ result = _dbd_result_create(conn, (void *)res, (res ? mysql_num_rows(res) : 0), mysql_affected_rows((MYSQL *)conn-connection)); --- I hope I've explained this so you can understand it. I have a couple of test programs if it would help. Feel free to let me know if you have any questions or if you would like additional information. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
[Libdbi-drivers-devel] Bug with mysql driver with errors from timeouts from mysql
Hi Chuck, Chuck Hemker writes: When you get a lock timeout on a select, it is reported by mysql by returning a null from mysql_store_result. This currently isn't noticed by the driver. In dbd_query (and dbd_query_null) in dbd_mysql.c there should be 3 cases: mysql_store_result() != null good select mysql_store_result() = null mysql_field_count() = 0 good insert ... mysql_store_result() = null mysql_field_count() 0 error on select thanks for reporting this problem and for suggesting a fix. Is this MySQL behaviour documented somewhere, or did you just observe this? Is your fix supposed to work with all MySQL releases since, say, 4.0? If both answers are yes, your suggested fix is likely to make its way into the driver. regards, Markus -- Markus Hoenicka markus.hoeni...@cats.de (Spam-protected email: replace the quadrupeds with mhoenicka) http://www.mhoenicka.de -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
Re: [Libdbi-drivers-devel] Bug with mysql driver with errors from timeouts from mysql
On Wed, 29 Apr 2009 00:05:33 +0200 Markus Hoenicka markus.hoeni...@mhoenicka.de wrote: Hi Chuck, Chuck Hemker writes: When you get a lock timeout on a select, it is reported by mysql by returning a null from mysql_store_result. This currently isn't noticed by the driver. In dbd_query (and dbd_query_null) in dbd_mysql.c there should be 3 cases: mysql_store_result() != null good select mysql_store_result() = null mysql_field_count() = 0 good insert ... mysql_store_result() = null mysql_field_count() 0 error on select thanks for reporting this problem and for suggesting a fix. Is this MySQL behaviour documented somewhere, or did you just observe this? Is your fix supposed to work with all MySQL releases since, say, 4.0? If both answers are yes, your suggested fix is likely to make its way into the driver. I haven't used the mysql api that much because I like libdbi. :) However, take a look a these pages that I found with a little bit of digging: In the mysql 5.0 manual: http://dev.mysql.com/doc/refman/5.0/en/null-mysql-store-result.html Why mysql_store_result() Sometimes Returns NULL After mysql_query() Returns Success ... You can always check whether the statement should have produced a non-empty result by calling mysql_field_count(). --- http://dev.mysql.com/doc/refman/5.0/en/mysql-field-count.html The normal use of this function is when mysql_store_result() returned NULL (and thus you have no result set pointer). In this case, you can call mysql_field_count() to determine whether mysql_store_result() should have produced a non-empty result. This allows the client program to take proper action without knowing whether the query was a SELECT (or SELECT-like) statement. Also has a bit of example code. --- These seem to be similar pages in the 3.23/4.0/4.1 manual: http://dev.mysql.com/doc/refman/4.1/en/null-mysql-store-result.html http://dev.mysql.com/doc/refman/4.1/en/mysql-field-count.html This one says: If you are using a version of MySQL earlier than 3.22.24, you should use unsigned int mysql_num_fields(MYSQL *mysql) instead. --- So it looks like it should work with mysql 3.22.24 or later. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
