Hi!
>>>>> "Yuri" == Yuri Dario <mc6530@stripped> writes:
<cut>
Yuri> Second, many tests are failing while performing 'check table t1'
Yuri> because of 'error 43 when updating keyfile'; errno 43 is EBADF here.
Yuri> So looking at mysql.trace, I discovered that my_pwrite() is failing to
Yuri> write on handle 11 (t1.myi). I don't see calls to my_close() between
Yuri> my_open() and my_pwrite(), so I don't understand why it doesn't work.
In the trace we have this:
T@4 : | | | | | | >lock_external
T@4 : | | | | | | | >mi_lock_database
T@4 : | | | | | | | | >my_lock
T@4 : | | | | | | | | | my: Fd: 9 Op: 0 start: 0 Length: 0 MyFlags: 32
T@4 : | | | | | | | | <my_lock
T@4 : | | | | | | | | >my_pread
T@4 : | | | | | | | | | my: Fd: 9 Seek: 0 Buffer: d2eb24 Count: 176 MyFlags: 4
T@4 : | | | | | | | | <my_pread
T@4 : | | | | | | | <mi_lock_database
Could there be some problem with the above lock so that it locks the
table against writing and that the write gives us a wrong errno ?
At least on Windows op: 0 to means UNLOCK, but I don't how things
works on OS/2.
On the other hand, if this doesn't work then you should get a LOT of
other problems.
I would suggest you to add some DBUG_PRINT information in my_pwrite()
to see if it's the lseek() or write() that fails.
Another thing to try is to run mysqld with --skip-locking; This will
disable the code in my_lock(). If things starts working after this,
then you know the problem is in the locking code.
Regards,
Monty
