OK,
the problem doesn't occur with --skip-locking. Still, I don't believe this to
be a lockd problem as the partition mysqld is working on is a local ext2 fs.
lockd isn't even running on the test system (no nfs). So, this leaves either
(in no particular sequence):
1. a mysql problem
2. a glibc
Hi,
first of all: the deadlock happened again today, this time with no slave
running so it isn't a replication issue. It seems we're getting closer as when
I did run 'show processlist', the pending query was (excerpt from output):
1666logreader 10.1.1.4syslog Query 114
Hi,
well, the query is over a network. Single switch with two VLANs between the
systems, network speed is *200MBit/s*. The php code structure executing was:
... prepare query ...
mysql_connect();
mysql_query();
mysql_fetch_row();
mysql_close();
... process and send data to browser ...
The table
Andreas Steinmetz writes:
Hi,
well, the query is over a network. Single switch with two VLANs between the
systems, network speed is *200MBit/s*. The php code structure executing was:
... prepare query ...
mysql_connect();
mysql_query();
mysql_fetch_row();
mysql_close();
...
Hi,
the inserts did not change the state after the select finished. The network is
running full duplex but the only problem I ever encountered with the cards was
initalization on fast systems. I fixed this and posted it to the linux kernel
mailing list (search for epic100).
If the problem
Hi,
unfortunately I can't set up a scenario that easily reproduces the problem. The
last lockups happened on saturday and today (monday). What I can confirm is:
1. It doesn't seem to be a slave related problem. During the last two lockups I
checked the master as well as the slave statuses, all
Peter Zaitsev writes:
Hello Andreas,
Thursday, February 01, 2001, 7:42:31 PM, you wrote:
I must confirm the problem with table locks. Mysql realy may deadlock
sometimes, and the funny thing is the solution to this case is to kill
the oldest locked thread waiting this condition
