Hello, Ingo!
* Ingo Strüwing <ingo@stripped> [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
