List:Commits« Previous MessageNext Message »
From:Vladislav Vaintroub Date:October 24 2008 1:13pm
Subject:RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)
Bug#38186, Bug#39789
View as plain text  

> -----Original Message-----
> From: Jim Starkey [mailto:jstarkey@stripped]
> Sent: Friday, October 24, 2008 3:52 AM
> To: Vladislav Vaintroub
> Cc: 'Ann W. Harrison'; Kevin.Lewis@stripped; 'Vladislav Vaintroub';
> commits@stripped; 'Falcon Team'
> Subject: Re: bzr commit into mysql-6.0-falcon-team branch
> (vvaintroub:2875) Bug#38186, Bug#39789
> 
> 
> Probably the best way to handle the problem is to take inventory of
> tablespace creation and deletion during pass1, deferring actual file
> deletion and creation (if necessary) to pass2 when you know what is
> actually going on.  Comparing filenames is too problematic, so trying
> to
> open the file and get either a file id or canonical file name is the
> way
> to go. 
files are compared based on their devicenumber/inode number, 
rsp dwVolumeSerialNumber /nFileIndex.

			
> I think you will find that all table space related SRL record types
> already carry tablespace id, both for incarnation checking and for find
> the tablespace the update is to be applied to.
> 
> In general, it is better to follow the established architecture than
> inventing new mechanisms without a compelling reason. 

No compelling reasons, since I'm lazy I'm trying to keep existing
implementation which has been so from the time of Nixon's resignation
(Philip (TM)).

> Using pass1 to
> take inventory, pass2 to handle physical updates, and pass 3 to apply
> logical updates works pretty well.  If we find something that requires
> changing the architecture, then we shouldn't hesitate to do so, but I
> don't think that is the case here.  If you think otherwise, please
> explain the reasons.

I do not think otherwise. But why handling of tablespaces in recovery has
been different from the start on. I guess reimplementing accounting for
missing tablespace in 30 classes and 90 methods today while fixing this bug
might be quite fun. if I look at things like SRLUpdateRecords, that carries
multiple updates to different tablespaces in a single record.

Thread
bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875) Bug#38186,Bug#39789Vladislav Vaintroub21 Oct
RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub23 Oct
RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub23 Oct
  • Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Ann W. Harrison23 Oct
    • RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub24 Oct
      • Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Jim Starkey24 Oct
        • RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub24 Oct
          • Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Jim Starkey26 Oct
RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub24 Oct