List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:June 2 2001 10:31pm
Subject:Re: check table failing under OS/2
View as plain text  
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
Thread
check table failing under OS/2Yuri Dario30 May
  • Re: check table failing under OS/2Sinisa Milivojevic31 May
  • check table failing under OS/2Michael Widenius1 Jun
    • Re: check table failing under OS/2Yuri Dario1 Jun
      • Re: check table failing under OS/2Michael Widenius1 Jun
        • Re: check table failing under OS/2Yuri Dario1 Jun
          • Re: check table failing under OS/2Michael Widenius2 Jun
            • Re: check table failing under OS/2Yuri Dario2 Jun
              • Re: check table failing under OS/2Michael Widenius3 Jun
                • Re: check table failing under OS/2Yuri Dario3 Jun
                  • Re: check table failing under OS/2Yuri Dario3 Jun
                    • Re: check table failing under OS/2Michael Widenius3 Jun
                      • Re: check table failing under OS/2Yuri Dario4 Jun
                  • Re: check table failing under OS/2Michael Widenius3 Jun
                    • Re: check table failing under OS/2Yuri Dario4 Jun
                      • Re: check table failing under OS/2Yuri Dario4 Jun
                        • Re: check table failing under OS/2Michael Widenius5 Jun
                      • Re: check table failing under OS/2Michael Widenius4 Jun
                        • Re: check table failing under OS/2Yuri Dario4 Jun
                          • Re: check table failing under OS/2Michael Widenius5 Jun
  • check table failing under OS/2Michael Widenius1 Jun
    • Re: check table failing under OS/2Yuri Dario1 Jun
    • Re: check table failing under OS/2Yuri Dario2 Jun
      • Re: check table failing under OS/2Michael Widenius3 Jun
        • Re: check table failing under OS/2Yuri Dario3 Jun
Re: check table failing under OS/2Yuri Dario5 Jun
Re: check table failing under OS/2Yuri Dario5 Jun
  • Re: check table failing under OS/2Michael Widenius6 Jun
    • Re: check table failing under OS/2Yuri Dario6 Jun
      • Re: check table failing under OS/2Michael Widenius7 Jun
        • Re: check table failing under OS/2Yuri Dario7 Jun
          • Re: check table failing under OS/2Michael Widenius11 Jun