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 2.2
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 Se
Andreas Steinmetz writes:
> 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 (sea
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 continue
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,
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,
> 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
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 we
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 con
