mariadb

Tree: 05aba79e98

Author	SHA1	Message	Date
Sergei Golubchik	05aba79e98	MDEV-4447 MariaDB sources should have unix-style line endings everywhere	12 years ago
Sergei Golubchik	9b9c138e2a	small cleanups	13 years ago
Sergei Golubchik	86c642056a	few fixes for test failures on windows (and collateral changes) mysql-test/t/innodb_mysql_lock.test: change the variable from the test, not from the .opt file. one mysqld restart less. mysql-test/t/lowercase_table4.test: fix dos line endings sql/handler.cc: don't access the uninitialized variable	13 years ago
unknown	08f128f633	Bug#60196 / Bug#11831040 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.	15 years ago
Magne Mahre	95d91c0f57	Bug #46941 crash with lower_case_table_names=2 and foreign key data dictionary confusion On file systems with case insensitive file names, and lower_case_table_names set to '2', the server could crash due to a table definition cache inconsistency. This is the default setting on MacOSX, but may also be set and used on MS Windows. The bug is caused by using two different strategies for creating the hash key for the table definition cache, resulting in failure to look up an entry which is present in the cache, or failure to delete an existing entry. One strategy was to use the real table name (with case preserved), and the other to use a normalized table name (i.e a lower case version). This is manifested in two cases. One is during 'DROP DATABASE', where all known files are removed. The removal from the table definition cache is done via a generated list of TABLE_LIST with keys (wrongly) created using the case preserved name. The other is during CREATE TABLE, where the cache lookup is also (wrongly) based on the case preserved name. The fix was to use only the normalized table name when creating hash keys. sql/sql_db.cc: Normalize table name (i.e lower case it) sql/sql_table.cc: table_name contains the normalized name alias contains the real table name	15 years ago

3 Commits (05aba79e981cfeb7e7b68bb31739ab8d443c4aea)