From: Ingo Strüwing
Date: February 6 2009 10:02am
Subject: Re: Bug still exists Re: bzr commit into mysql-6.0-backup branch
 (ingo.struewing:2737) Bug#40944
List-Archive: http://lists.mysql.com/commits/65449
Message-Id: <498C0A9F.1030106@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT

Hi Guilhem,

Guilhem Bichot, 06.02.2009 10:20:

...
> - RESTORE starts
> - it creates an empty table, opens and successfully locks it
> - another thread starts a SELECT: opens table (making it "in use"),
> blocks on the lock held by RESTORE
> - RESTORE restores the maria-packed data and index file, unlocks table,
> calls close_cached_tables() which does not close the table (because it's
> "in use" by the SELECT)
> - RESTORE goes into close_thread_tables(m_thd) (below) which starts by
> unlocking tables; immediately after that unlocking, the SELECT thread
> resumes and manages to lock the table (which still isn't closed)


Thank you for pointing this out!

...
> I am not sure that this problem will disappear when RESTORE will
> atomically create and restore data into the table without letting other
> clients open the table in between

...

> I suspect we'll need to involve the Runtime team's experts.


It may be good to have their opinion to my view:

The RESTORE locking scheme has been developed before Dmitri's Meta Data
Locks (MDL) existed. There seems to be common agreement that we should
refactor it so that it takes exclusive MDL for all tables to be
restored. Before even creating the tables, I think. Once this is done,
the SELECT would be blocked even before attempting to open the table. So
it wouldn't mark it "in_use". The lock would persist until RESTORE
finishes. That is, until after close_cached_tables().

...

Regards
Ingo
-- 
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring   HRB München 161028