Have a good vacation, Sergei.
>P_S has numerous problems because of physical frm files. There are quite
>a few bugs there, for example related to users doing CREATE/ALTER/DROP
>on P_S tables.
>
>frm tables have to be pre-created in mysql_install_db (that's the script
>that creates all system tables, like mysql.user, and so on).
>
>This design doesn't really work for plugins. Any plugin may install I_S
>table any time, so we cannot pre-create them all. And a user can unload
>a plugin any time - the table have to dissapear automatically. And a
>user can load a new version of the plugin with a different structure
>of the same I_S table - the table must be automatically created in the
>new format. Supporting all this with physical frm files would be really
>painful.
>
>So, I'd rather have I_S tables completely virtual, like they are now.
>No physical frm files.
>
I got what you said. I have a new idea.
The traditional implementation, which has .frm file, is:
dispatch_command -> mysql_parse -> mysql_execute_command -> execute_sqlcom_select
-> open_and_lock_tables -> open_and_lock_tables_derived -> open_tables
->open_table
-> open_table_from_share -> ha_open -> open(storage engine).
The TABLE *table and TABLE_SHARE *table_share structures are filled in open_table and
open_table_from_share from informations provided .frm file.
And my new idea is:
Ommits the functions open_table and open_table_from_share, after reaches I_S storage
engine, ha_infoschema::open
fills the TABLE *table and TABLE_SHARE *table_share structures by our own definitions of
I_S tables.
After that, others functions of I_S storage engine, like rnd_next, index_read etc, can use
TABLE *table and
TABLE_SHARE *table_share structures.
If user does not install the I_S storage engine plugin, in funciton open_tables return
message like "INFORMATION SCHEMA
Storage engine does not install.".
Does it work?
Launchpad sends me a mail, says:
>Temporarily disabled lp:~scut-tang/mysql-server/mysql-6.0-infoschema
>Launchpad recently had a temporary unplanned outage to its codehosting
>system, caused by one of our scripts going crazy and chewing up all
>available memory.
>After some investigation, we found that the script was going out of
>memory while processing the branch lp:~scut-tang/mysql-
>server/mysql-6.0-infoschema.
>In order to restore full functionality to Launchpad's users, we
>temporarily disabled all processing of this branch. This branch will be
>completely unavailable while this block is in place. We're sorry to have
>to do this.
I will contact the administrator and solve it.
Regards.
Robin
业务订单流失怎么办？
