Re: reopen_tables() [Re: bk commit - 4.1 tree (istruewing:1.2630) BUG#26379]

Hello, Ingo!

• Ingo Strüwing <ingo@mysql.com> [07/09/07 20:38]:
  > Dmitri Lenev, 07.09.2007 13:29:
  > > AFAIU all places where mysql_lock_tables() is used can be classified as:
  > > *) Places, like open_ltable(), where it is trivial to restart open and
  > > lock tables loop.
  > > *) Places where an attempt to lock a table should never be aborted...
  >
  > In which category would you put handle_delayed_insert()? It looks quite
  > complicated to restart at open here.
  

As far as I understand code implementing INSERT DELAYED in above case we can simply add loop around call to mysql_lock_tables() which will close the table in question, open it and then try to lock it again (note that value of Delayed_insert::table should be updated in the process). Of course this is not exactly "restarting the loop" but it is fairly close to the current behavior implemented by wait_for_tables().

Having said that I should admit after looking at handle_delayed_insert() and related code I've started to think that the fact that we simply reopen tables in this case instead of "restarting open and lock tables loop", which should also involve checks and other operations which are done at the begging of handle_delayed_insert(), might cause bugs. For example, what will happen if new version of table which we've got after implicit table reopen in mysql_lock_tables() has triggers? I think it makes sense to investigate this issue and possibly report it as separate problem...

What is your opinion ?

> I'll try to change the other functions. May come back with more
> questions. The sad thing is that my new patch was almost ready...

Well, if your patch already modifies reopen_tables() in such way that it can successfully handle merge tables in _both_ scenarios of its usage (one in which merge table should be reopened even if number of underlying tables has increased and another one in which such attempt should fail) then probably you can ignore my proposal about getting rid of wait_for_tables() (altough I still think that we should remove this function/code path in the long term).

P.S. Thanks a lot for all your efforts to solve this problem in a clean

     and future-proof way!

-- 
Dmitri Lenev, Software Developer
MySQL AB, www.mysql.com

Are you MySQL certified?  
http://www.mysql.com/certification

-- 
MySQL Code Commits Mailing List
For list archives: 
http://lists.mysql.com/commits
To unsubscribe:    
http://lists.mysql.com/commits?unsub=lists@pantek.com

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek