ID: 19529
User updated 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:
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
Previous Comments:
------------------------------------------------------------------------
[2002-10-01 12:52:12] [EMAIL PROTECTED]
I have been looking through CVS log at lxr.php.net to see what has
changed in mysql support in PHP this last year. One change was the
inclusion of mysql.connect_timeout.
In the docs it says the default is 0. This is backed up by the
default:
496 mysql_globals->connect_timeout = 0;
However, I expected the line:
352 STD_PHP_INI_ENTRY_EX("mysql.connect_timeout","",...
to have ("mysql.connect_timeout","0",
Also, things seem odd to me:
651 if (connect_timeout != -1)
749 if (connect_timeout != -1)
Why is it checking for the connect_timeout as to -1 rather than zero? I
think telling mysql that the connect timeout is zero causes the
problems: the connection closes really quick! Well, it seems to be a
race condition anyhow. As a default. Ick. And exploited by the time the
connect is reused.
I set mysql.connect_timeout = -1 in the .ini file as a temp workaround.
Seems to be working. I will wait a day and report if this indeed
eliminates these errors.
------------------------------------------------------------------------
[2002-10-01 12:10:20] [EMAIL PROTECTED]
Last thing! I do not use transactions or any transactional table
handlers. Just plain MySQL with MySQL table types.
------------------------------------------------------------------------
[2002-10-01 11:44:41] [EMAIL PROTECTED]
Sorry to reopen. I think it was changed to Bogus because of MySQL 4
usage. However, I use 3.23.49a for the server and use the built-in
client software that comes with PHP 4.2.3. Other users see the same
errors with 4.0.x servers.
Essentially this is a client PHP issue.
I am now logging all mysql errors to a file so I can see how different
changes affect things. As far as I can see, this condition only happens
under high load and only when using pconnect.
Again, nothing to do with MySQL 4.
------------------------------------------------------------------------
[2002-09-22 08:47:09] [EMAIL PROTECTED]
I agree MySQL 4.x is still in beta quality (although it works quite
well), but before upgrading to php 4.2.1 I had strictly no problem with
PHP / MySQL 4.x (and I'm using MySQL 4.x libs).
------------------------------------------------------------------------
[2002-09-21 15:17:40] [EMAIL PROTECTED]
IMHO, it's not a good idea to use MySQL 4.x. It's certainly not a good
idea to use 3.x libs to access a 4.x server.
------------------------------------------------------------------------
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
