Hi!
>>>>> "Yuri" == Yuri Dario <mc6530@stripped> writes:
Yuri> Hi Monty,
>> 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
>> At least on Windows op: 0 to means UNLOCK, but I don't how things
Yuri> under OS/2, 0 means F_RDLCK.
Yuri> I found the error: when using F_RDLCK, the actual locking code was
Yuri> locking the range, and making the file access read-only to all
Yuri> processes (including mysqld).
Yuri> Removing the read-only flag, fixed locking capabilities.
Yuri> How is supposed to work F_RDLCK under Unix? because looking at Windows
Yuri> code, I see that F_RDLCK and F_WRLCK are mapped to LK_NBCLK and
Yuri> LB_NBRLCK: in the Borland C++ runtime lib, these locks are treated in
Yuri> the same way, without readonly settings.
If I understand this correctly, the problem was that you was doing a
readlock instead of an unlock.
MySQL should never write on a file that just has a readlock.
The write you got in the log, was a write on a not locked file.
This doesn't however has anything to do with how Unix works; The locks
and read/write access on a file are independent.
In other words, it's ok from the OS's point of view if you write to a
file on which you have a readlock. Practically you will however have
problems if many clients just uses readlocks and then updates files...
Regards,
Monty
