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 4:19 PM
> To: Vladislav Vaintroub
> Cc: 'Vladislav Vaintroub'; commits@stripped; Falcon Team
> Subject: Re: bzr commit into mysql-6.0-falcon-team branch
> (vvaintroub:2875) Bug#38186, Bug#39789
> 
> > Vlad wrote;
> > 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.
> 
> When the SRLDropTablespace for "A" comes in, you say the file is
> logically empty.  So I do not understand what is keeping it from being
> completely deleted at this point.  

> What is still pending in the serial
> log or memory which may refer to this file that keeps it from being
> deleted?

The tablespace "B" that refers to the same file is still pending in memory
(and in serial log).

Keep in mind, that all possible tablespaces are created in memory and on
disk during pass1() or in Tablespace::boostrap(). They are never deleted 
until REDO phase comes. REDO does not recreate Tablespaces - why should it,
they are already present after the pass1.
IF they are not present during pass1 or pass2, we ultimately suck during in
recovery on IO::read().


> If there are things done by the recovery thread that need to be
> followed
> up later by the gopher threads, then tell me what those are.
> 
> Ultimately, I want to lead this discussion into an alternate solution
> (for part of your changes).

This would mean the current solution is not optimal. It is quite simple and
the changes are limited
To SRLCreateTableSpace and SRLDropTableSpace only.

If you want all operations skip tablespace that is deleted at the end and do
this in phase1,phase2 and REDO
changes are necessary.


>  That is, is it possible for the
> SRLCreateTableSpace for "A" and SRLDropTablespace for "A" to be
> completely skipped since that tablespace is an old incarnation.  Will
> it
> be necesary to add tablespaceIDs to all other serialLog record types?
> I
> don't think so. 
> A tablespace must be logicaly empty before it is
> dropped, so the table incarnations should be already handled.

It will be necessary to skip all operations on this tablespace during all
phases.
The file is already accessed during phase1

> We track multiple incarnations of objects through the serial log with
> RecoveryObjects;
> 
> \storage\falcon\SerialLog.h(170):  RecoveryObjects *recoveryPages;
> \storage\falcon\SerialLog.h(171):  RecoveryObjects *recoverySections;
> \storage\falcon\SerialLog.h(172):  RecoveryObjects *recoveryIndexes;
> 
> Incarnations of tables are tracked through the section pages that
> locate
> them.  Maybe we should introduce;
> 
> RecoveryObjects *recoveryTablespaces;

I track the multiple incarnations of datafiles in recoveryDatafiles.
There are no way tablespace can have multiple incarnations. Tablespace is
assigned unique id that is created with Sequence, means always unique.