MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Rafal Somla Date:November 3 2009 3:25pm
Subject:Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)
Bug#42895 WL#4844
View as plain text  
Hi Ingo,

What do you think about the following proposition.

Ingo Strüwing wrote:
...
>>>  # Perform restore
>>> +--echo # RESTORE of a compressed MyISAM table issues two warnings:
>>> +--echo # "Table is read only" and "Deadlock found when trying to get
>>> lock".
>>> +--echo # This results from an internal call of FLUSH TABLES.
>> [1] First one is perhaps ok, but second one does not look good. I'm
>> thinking if warnings should not be disabled when FLUSH TABLES is called
>> from inside RESTORE. But then we might miss some relevant warnings...
> 
> 
> Yes, that's what I thought too. When developing the patch before
> Øystein's warning fixes were pushed, these warnings were simply dropped.
> I checked that the same behavior happened there too. It is unfortunate
> that it happens at all. But this results from MyISAM specifics with
> compressed tables. In this case we cannot get write locks on them. But
> as we want to unlock after flush anyway, we don't need the locks, and
> thus can accept the problem. But as you say, it may be good to see other
> warnings, if they pop up.
> 
> A final solution could be a FLUSH TABLES WITH UNLOCK statement. But I'm
> hearing yells, imaging to have proposed it...
> 

How about installing an error handler which will analyse warnings reported 
during FLUSH TABLES and either ignore them or forward to error stack. Such 
handler could be installed inside flush_tables() before call to 
run_service_interface_sql() and removed after it is done. Would it be very 
difficult to implement such solution?

Rafal

Thread
bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Ingo Struewing28 Oct
  • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Rafal Somla29 Oct
    • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Ingo Strüwing29 Oct
      • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Rafal Somla30 Oct
        • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Ingo Strüwing31 Oct
  • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Rafal Somla30 Oct
    • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Ingo Strüwing2 Nov
      • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Rafal Somla3 Nov
      • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Konstantin Osipov3 Nov
        • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Ingo Strüwing3 Nov
          • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Konstantin Osipov3 Nov
  • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Rafal Somla16 Nov
    • Re: bzr commit into mysql-6.0-backup branch (ingo.struewing:2882)Bug#42895 WL#4844Ingo Strüwing17 Nov