ID: 19529 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Linux 2.4.18 PHP Version: 4.2.3 New Comment:
I agree that the most plausible cause of the problem is in the _restore_connection_defaults function, which is the one responsible for doing the ROLLBACK. That theory would seem to be supported by the fact that the problem disappears when disabling persistent connections (since the function does nothing when the connection isn't persistent). What I don't get is why executing ROLLBACK on a straight-MyISAM database would cause problems. Is that a bug in MySQL? If the ROLLBACK isn't the problem, it would have to be either the SET AUTOCOMMIT=1 or the stuff about unsetting the selected DB. Since my application uses only one DB and no transactions, I'm going to just disable the entire function and recompile. Previous Comments: ------------------------------------------------------------------------ [2002-10-06 09:58:10] [EMAIL PROTECTED] What happens is that the mysql connection that gets the problem is locked up. It won't ever work again. After a while all of our mysql connections showed the problem making the site completely unusable. As of v4.2.3 php does a ROLLBACK each time connection is re-used. ROLLBACKS will give an error if updates have been done on a MyISAM table, I have removed that query now. Will see if that solves it. It looks like all us are running quite many queries per second? I see the problem on a site running 60+ queries per second. ------------------------------------------------------------------------ [2002-10-06 08:13:00] [EMAIL PROTECTED] Another note: [EMAIL PROTECTED] states that the problem seems to only happen at high load, and is intermittent. In my experience, it seems to happen after long periods of running. More specifically, my (production) system will run fine for hours with 30+ queries/second, and then suddenly start having several of the "Commands out of sync" error messages per second. They are still intermittent (ie. they don't appear at every query), but these symptoms seem to indicate a memory leak or other delayed-impact bug as the cause of the problems. ------------------------------------------------------------------------ [2002-10-06 07:21:37] [EMAIL PROTECTED] I'm having the same problem; it appears to have started when I upgraded PHP from 4.2.2 to 4.2.3. At the same time, I upgraded Apache from 1.3.26 to 1.3.27. I wasn't using the built-in client lib, but have switched to it now... although after reading the comments here, I don't expect that to fix things. I'd just like to emphasize that I'm experiencing this bug using stable versions of both Apache (1.3.27) and MySQL (3.23.44). PHP definitely seems to be the culprit. ------------------------------------------------------------------------ [2002-10-05 14:51:46] [EMAIL PROTECTED] I'm having this problem also. I replaced all pconnects with connect, this makes thing work. But the httpd processes are leaking alot of memory. Had to restart httpd after a while when it was using 900MB swap. It looks like php is not correctly freeing query memory when there are still rows left to fetch. I'm running mysql 4.0.4, it was working well until I upgraded the php to 4.2.3. I have tried with both the built in mysql client lib and the 4.0.4 one. ------------------------------------------------------------------------ [2002-10-01 19:36:44] [EMAIL PROTECTED] Last data point: the workaround in my last message works with 3.23.x but not 4.0.x as far as I can tell. Here is my test matrix: PHP client using built-in mysql libs. Server: 3.23.49a 4.0.2 -------- ---- connect OK OK pconnect fail fail pconnect OK fail w/ fix ------------------------------------------------------------------------ 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/19529 -- Edit this bug report at http://bugs.php.net/?id=19529&edit=1