With this change, the index prefix column length lifted from 767 bytes
to 3072 bytes if "innodb_large_prefix" is set to "true".
rb://603 approved by Marko
With this change, the index prefix column length lifted from 767 bytes
to 3072 bytes if "innodb_large_prefix" is set to "true".
rb://603 approved by Marko
large prefix (>=768). Table with such large prefix index will not
be loaded into memory (for its metadata), unless innodb_force_recovery
is on.
rb://604 Approved by Marko
large prefix (>=768). Table with such large prefix index will not
be loaded into memory (for its metadata), unless innodb_force_recovery
is on.
rb://604 Approved by Marko
The innoDB global variable srv_lower_case_table_names is set to the value of lower_case_table_names declared in mysqld.h server in ha_innodb.cc. Since this variable can change at runtime, it is reset for each handler call to ::create, ::open, ::rename_table & ::delete_table.
But it is possible for tables to be implicitly opened before an explicit handler call is made when an engine is first started or restarted. I was able to reproduce that with the testcase in this patch on a version of InnoDB from 2 weeks ago. It seemed like the change buffer entries for the secondary key was getting put into pages after the restart. (But I am not sure, I did not write down the call stack while it was reproducing.) In the current code, the implicit open, which is actually a call to dict_load_foreigns(), does not occur with this testcase.
The change is to replace srv_lower_case_table_names by an interface function in innodb.cc that retrieves the server global variable when it is needed.
The innoDB global variable srv_lower_case_table_names is set to the value of lower_case_table_names declared in mysqld.h server in ha_innodb.cc. Since this variable can change at runtime, it is reset for each handler call to ::create, ::open, ::rename_table & ::delete_table.
But it is possible for tables to be implicitly opened before an explicit handler call is made when an engine is first started or restarted. I was able to reproduce that with the testcase in this patch on a version of InnoDB from 2 weeks ago. It seemed like the change buffer entries for the secondary key was getting put into pages after the restart. (But I am not sure, I did not write down the call stack while it was reproducing.) In the current code, the implicit open, which is actually a call to dict_load_foreigns(), does not occur with this testcase.
The change is to replace srv_lower_case_table_names by an interface function in innodb.cc that retrieves the server global variable when it is needed.
Setting lowercase_table_names to 2 on Windows causing Foreign Key problems
This problem was exposed by the fix for Bug#55222. There was a codepath in dict0load.c,
dict_load_foreigns() that made sure the table name matched case sensitive in order to
load a referenced table into the dictionary as needed. If an engine is rebooted which
accesses a table with foreign keys, and lower_case_table_names=2, then the table with
foreign keys will get an error when it is changed (insert/updated/delete).
Once the referenced tables are loaded into the dictionary cache by a select statement
on those tables, the same change would succeed because the affected code path would
not get followed.
Setting lowercase_table_names to 2 on Windows causing Foreign Key problems
This problem was exposed by the fix for Bug#55222. There was a codepath in dict0load.c,
dict_load_foreigns() that made sure the table name matched case sensitive in order to
load a referenced table into the dictionary as needed. If an engine is rebooted which
accesses a table with foreign keys, and lower_case_table_names=2, then the table with
foreign keys will get an error when it is changed (insert/updated/delete).
Once the referenced tables are loaded into the dictionary cache by a select statement
on those tables, the same change would succeed because the affected code path would
not get followed.
The bug would cause a crash of InnoDB if a non-standard or unknown table
flags existed in a SYS_TABLES record. This is important because the next
file version, Cheetah, will identify itself by expanding this field. So
unless this is fixed, an older engine that tries to open a table in a
tablespace with a newer file version will crash instead of report an error
and refuse to open the table, as it should do.
Reviewed at RB://583. Approved by Marko.
The bug would cause a crash of InnoDB if a non-standard or unknown table
flags existed in a SYS_TABLES record. This is important because the next
file version, Cheetah, will identify itself by expanding this field. So
unless this is fixed, an older engine that tries to open a table in a
tablespace with a newer file version will crash instead of report an error
and refuse to open the table, as it should do.
Reviewed at RB://583. Approved by Marko.
"rows examined" estimates". This change implements "innodb_stats_method"
with options of "nulls_equal", "nulls_unequal" and "null_ignored".
rb://553 approved by Marko
"rows examined" estimates". This change implements "innodb_stats_method"
with options of "nulls_equal", "nulls_unequal" and "null_ignored".
rb://553 approved by Marko
This adds 64 new rows to performance_schema.rwlock_instances.
This patch will make perfschema.binlog_mix perfschema.binlog_row tests fail,
but they will be fixed by http://lists.mysql.com/commits/127862
Approved by: Jimmy (rb://554)
This adds 64 new rows to performance_schema.rwlock_instances.
This patch will make perfschema.binlog_mix perfschema.binlog_row tests fail,
but they will be fixed by http://lists.mysql.com/commits/127862
Approved by: Jimmy (rb://554)
mysql-trunk-innodb in rev revno: 3367 Tue 2010-12-07 02:25:25-0800.
The crash happens only when lower_case_table_names=2, such as on MacOS,
when running the new testcase innodb-system-table-view. Specifically,
it crashes when any query is made against the INFORMATION_SCHEMA.
INNODB_SYS_FOREIGN table. The function dict_process_sys_foreign_rec()
is only used for displaying SYS_FOREIGN records so it does not need a
lookup version of those names to be allocated. In this patch, those new
function calls are deleted.
mysql-trunk-innodb in rev revno: 3367 Tue 2010-12-07 02:25:25-0800.
The crash happens only when lower_case_table_names=2, such as on MacOS,
when running the new testcase innodb-system-table-view. Specifically,
it crashes when any query is made against the INFORMATION_SCHEMA.
INNODB_SYS_FOREIGN table. The function dict_process_sys_foreign_rec()
is only used for displaying SYS_FOREIGN records so it does not need a
lookup version of those names to be allocated. In this patch, those new
function calls are deleted.
InnoDB does not attempt to handle lower_case_table_names == 2 when looking
up foreign table names and referenced table name. It turned that server
variable into a boolean and ignored the possibility of it being '2'.
The setting lower_case_table_names == 2 means that it should be stored and
displayed in mixed case as given, but compared internally in lower case.
Normally the server deals with this since it stores table names. But
InnoDB stores referential constraints for the server, so it needs to keep
track of both lower case and given names.
This solution creates two table name pointers for each foreign and referenced
table name. One to display the name, and one to look it up. Both pointers
point to the same allocated string unless this setting is 2. So the overhead
added is not too much.
Two functions are created in dict0mem.c to populate the ..._lookup versions
of these pointers. Both dict_mem_foreign_table_name_lookup_set() and
dict_mem_referenced_table_name_lookup_set() are called 5 times each.
InnoDB does not attempt to handle lower_case_table_names == 2 when looking
up foreign table names and referenced table name. It turned that server
variable into a boolean and ignored the possibility of it being '2'.
The setting lower_case_table_names == 2 means that it should be stored and
displayed in mixed case as given, but compared internally in lower case.
Normally the server deals with this since it stores table names. But
InnoDB stores referential constraints for the server, so it needs to keep
track of both lower case and given names.
This solution creates two table name pointers for each foreign and referenced
table name. One to display the name, and one to look it up. Both pointers
point to the same allocated string unless this setting is 2. So the overhead
added is not too much.
Two functions are created in dict0mem.c to populate the ..._lookup versions
of these pointers. Both dict_mem_foreign_table_name_lookup_set() and
dict_mem_referenced_table_name_lookup_set() are called 5 times each.
