ID: 49511 Updated by: u...@php.net Reported By: casper at procurios dot nl -Status: Assigned +Status: To be documented Bug Type: MySQL related Operating System: * PHP Version: 5.3, 6 (2009-09-09) Assigned To: mysql New Comment:
It should be fixed now, please test a SVN snapshot. We may want to stress out in the documentation that a) users cannot set MYSQL_OPT_READ_TIMEOUT through an API call and, if we ever allow setting it, there may be subtle differences between libmysql and streams how to interpret the value of MYSQL_OPT_READ_TIMEOUT. Using mysqlnd means using PHP streams. PHP streams documentation needs to be consulted on such details not dev.mysql.com documentation on the MySQL Client Library AKA libmysql AKA C-API. Previous Comments: ------------------------------------------------------------------------ [2009-09-16 15:00:54] s...@php.net Automatic comment from SVN on behalf of uw Revision: http://svn.php.net/viewvc/?view=revision&revision=288378 Log: Fix and tests for bug #49511 . mysqlnd and the MySQL Client Library (libmysql) use different networking APIs. mysqlnd does use PHP streams whereas libmysql uses its own wrapper of the operating level network calls. PHP sets by default a read timeout of 60s for streams - php.ini, default_socket_timeout. This default applies to all streams that set no other timeout value. mysqlnd has not set any other value and therefore it connections of long running queries can have been cut off after default_socket_timeout seconds resulting in a 2006 - MySQL Server has gone away error message. The MySQL Client Library sets a default timeout of 365 * 24 * 3600 seconds (1year) and waits for other timeouts to happen, e.g. TCP/IP timeouts. mysqlnd now uses the same very long timeout. The value is configurable through a new php.ini setting: mysqlnd.net_read_timeout. mysqlnd.net_read_timeout gets used by any extension (ext/mysql, ext/mysqli, PDO_MySQL) that uses mysqlnd. mysqlnd tells PHP Streams to use mysqlnd.net_read_timeout. Please note that there may be subtle differences between MYSQL_OPT_READ_TIMEOUT from the MySQL Client Library and PHP Streams. E.g. MYSQL_OPT_READ_TIMEOUT is documented to work only for TCP/IP connections and, prior to MySQL 5.1.2, only for Windows. PHP streams may not have this limitation. Please check the streams documentation, if in doubt. ------------------------------------------------------------------------ [2009-09-16 13:43:06] u...@php.net For the public and on "libmysql not compatible": Pierre and I had an argue on IRC. While we still disagree in some points we concluded it would be benefitial to document some background information for users - either in the docs or on the wiki. On the bug itself: I am waiting for Andrey to review a patch. ------------------------------------------------------------------------ [2009-09-16 12:13:45] u...@php.net Any bug reports on libmysql crashes we could work on? ------------------------------------------------------------------------ [2009-09-16 12:04:47] paj...@php.net I'm not blaming anyone, I'm only saying that we can forget libmysql on windows, no matter which compiler we use as the crashes occur too with the other versions. Now, it seems that you insist that we should use libmysql. Does it mean that mysqlnd is not usable or will not be usable in a production environment in a reasonable time frame (aka 5.3.1)? No irony meant here, but if it is the case then we have a serious problem to solve. ------------------------------------------------------------------------ [2009-09-16 11:46:38] u...@php.net Pierre, I already stated that MySQL does no longer support VC6. MySQL does not support VC6 because Microsoft itself does not support it. Who to blame? It depends on how you feel about VC6 being EOL'd. If you think it should not have been EOL'd, you need to blame both Microsoft and users of Microsoft products, such as MySQL. If you consider the EOL of VC6 as reasonable, the root cause of the VC6 trouble is neither Microsoft nor MySQL. The trouble is caused by those who still use VC6 for their binaries and/or do not make their source compile with recent versions of Visual Studio and therefore cause incompatibilities. Not supporting VC6 is not a bug, it is a feature decision. Not supporting compilers which are out of maintenance, is a pretty sane policy in my eyes considering lack of vendor support, lack of bug fixes, lack of support for modern hardware. VC6 is from the same generation as GCC 2.8.0. I wonder how many of us bother about GCC 2.8.0 ... For every reasonable current (no GCC 2.8 no VC6!) environment the availability of a binary (here: libmysql) is unrelated to the question if a software can be used. I am sure that there are Linux systems which use a glibc (stdc++, etc. ) that is not compatible with the glibc used to build a certain software. This does not necessarily mean that you cannot use the software altogether. As a last resort you can always try to compile it yourself on the target platform. I am aware how inconvenient it is for php.net to build tons of libraries from source. Any request for a pre-compiled binary that uses CRT x.y is as valid as a request for glibc x.y. It is good and correct to precisely repeat any build request - preferably at bugs.mysql.com. This is the best place to make MySQL do anything for you. Anyway, I still cannot believe that it is *impossible* to the the MySQL Client Library together with ext/mysqli, ext/mysql or PDO_MYSQL. If you have any problems compiling the MySQL Client Library from source using a recent version of Visual Studio, please report it as a bug on bugs.mysql.com. If any of those self-compiled libraries cannot be used because of faulty coding leading to stinky run-time dependencies, please report it as a bug on bugs.mysql.com. If you think the code of the extensions needs to be tweaked to be compatible with any such binary, please report it as a bug on bugs.php.net or bugs.mysql.com. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49511 -- Edit this bug report at http://bugs.php.net/?id=49511&edit=1
