ID: 19529
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: MySQL related
Operating System: Linux 2.4.18
PHP Version: 4.2.3
Assigned To: georg
New Comment:
Removing the ROLLBACK seems to have fixed the problem for me too.
Reading the MySQL docs on the error message in question, it would seem
that just adding a mysql_free_result call before executing the ROLLBACK
query might fix things. I noticed that the PgSQL extension does
something similar when rolling back transactions at shutdown.
Previous Comments:
------------------------------------------------------------------------
[2002-10-06 14:51:51] [EMAIL PROTECTED]
Currently, neither mysql 4.x or 3.x supports enough functionality for
handling some problems when using persistent connections, e.g.
restoring session variables to global variables,
restoring auto_commit, unsetting user variables etc.
The probably error is not MySQL-version dependend. The 4.x clientlib is
100% backwards compatible to MySQL 3.x (> .23).
For some more information, it would be useful, if you could send me
some sources...
assigned to myself.
Georg
------------------------------------------------------------------------
[2002-10-06 12:23:42] [EMAIL PROTECTED]
The problem seems to have disappeared when the ROLLBACK was removed.
------------------------------------------------------------------------
[2002-10-06 11:02:28] [EMAIL PROTECTED]
Scratch the above; I was looking at the current CVS version. In 4.2.3
the function is still called _rollback_mysql_transactions and only does
the ROLLBACK, nothing more.
I just disabled the ROLLBACK as well, so if neither Erik nor myself see
any more errors, I think it's safe to assume that's where the problem
is. But shouldn't it always be safe to execute a rollback in MySQL,
even if transactions aren't in use?
------------------------------------------------------------------------
[2002-10-06 10:14:36] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
