RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875) Bug#38186, Bug#39789

[Vladislav Vaintroub]

> -----Original Message-----
> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
> Sent: Thursday, October 23, 2008 6:30 AM
> To: Vladislav Vaintroub
> Cc: commits@stripped
> Subject: Re: bzr commit into mysql-6.0-falcon-team branch
> (vvaintroub:2875) Bug#38186, Bug#39789
> 
> Vlad,
> 
> I have some questions;
> 
>  >       -Drop tablespace in REDO phase removed datafiles without
>  >       taking into account that some of them should stay after the
>  >       recovery.
> Why?  If tablespaced are sequentially deleted and recreated before the
> recovery when there are multiple threads, Why can't they be handled
> sequentially by the one recovery thread?

Tablespace can be deleted, file must not be removed without further check in
the redo phase of dropTablespace,  because among other things it is not
recreated in the redo phase of  createTablespace.

Create tablespace A add datafile "file" engine falcon;
Drop tablespace A engine falcon;
Create tablespace B add datafile "file" engine falcon;

Prior to this patch, file "file" would be deleted but tablespace B will
still exist after recovery without the corresponding datafile.

>  >       In this case, even if metadata for tablespace
>  >       would be present after recovery, the data is lost together
>  >       with the file.
> Why is metadata for a dropped tablespace present after it is dropped?

Explained above

> It looks like your changes assure that a tablespace file that is
> dropped
> is now dropped immediately.  Great.

Yes, this is advantage to the prior solution. There is one inconsistency
recovery has to care about though. File disappears before tablespace
disappears from system tables, i.e before gopher processes the commit
message for system transaction.

Thus file that is in system table but not on the disk is created in
Tablespace::bootstrap. Eventually it will be deleted again after recovery.

>  >       Recovery for "drop tablespace A" would delete file used
>  >       by tablespace B and invalidate table T.
> What about the create tablespace B that comes right after that?
> 
>  >       Solution for this problem is to calculate whether datafiles
>  >       should stay after recovery or can be deleted. Calculation done
>  >       in the pass1 of recovery, deletion in the REDO phase.
> This calculation is done by log->tableSpaceManager->findTableSpace()?
> Why would/should it still be there after a drop tablespace?
> 
> 
> Obviously, I don't understand this solution...  Please explain.

Ok, with the prior example

Create tablespace A add datafile "file" engine falcon;
Drop tablespace A engine falcon;
Create tablespace B add datafile "file" engine falcon;


Recovery phase1 sees

SRLCreateTableSpace for "A" and marks datafile "file" as active
SRLDropTablespace for "A" and marks datafile "file" as inactive
SRLCreateTablespace for "B" and marks datafile "file" as active again

The final state of "file" is active and thus SRLDropTableSpace::redo does
not delete "file" when processing SRLDropTablespace, because it will used by
tablespace "B" after it. The "file"  is logically empty at this stage though
- drop tablespace succeeds only on empty tablespaces
SRLDropTableSpace::redo will remove the entries for "A" from internal
hashtables and lists so on.