| 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.
