Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
Addendum fixes after changing the condition variable
for the global read lock.
The stress test suite revealed some deadlocks. Some were
related to the new condition variable (COND_global_read_lock)
and some were general problems with the global read lock.
It is now necessary to signal COND_global_read_lock whenever
COND_refresh is signalled.
We need to wait for the release of a global read lock if one
is set before every operation that requires a write lock.
But we must not wait if we have locked tables by LOCK TABLES.
After setting a global read lock a thread waits until all
write locks are released.
An UNIQUE KEY consisting of NOT NULL columns
was displayed as PRIMARY KEY in "DESC t1".
According to the code, that was intentional
behaviour for some reasons unknown to me.
This code was written before bitkeeper time,
so I cannot check who and why made this.
After discussing on dev-public, a decision
was made to remove this code
with PREPARE fails with weird error".
More generally, re-executing a stored procedure with a complex SP cursor query
could lead to a crash.
The cause of the problem was that SP cursor queries were not optimized
properly at first execution: their parse tree belongs to sp_instr_cpush,
not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
cursor was declared, not when it was opened. This led to loss of optimization
transformations performed at first execution, as sp_instr_copen saw that the
query is already "EXECUTED" and therefore either not ran first-execution
related blocks or wrongly rolled back the transformations caused by
first-execution code.
The fix is to update the state of the parsed tree only when the tree is
executed, as opposed to when the instruction containing the tree is executed.
Assignment if i->state is moved to reset_lex_and_exec_core.
This bug in Field_string::cmp resulted in a wrong comparison
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
Wrong key comparisons could lead to wrong result sets if
the selected query execution plan used a range scan by
a partial index over a utf8 character field.
This also caused wrong results in many other cases.
functions in queries
Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
results in error 124 (wrong index) from storage engine.
The problem was that optimizer use disabled index to optimize
MAX()/MIN(). Normally it must skip disabled index and perform
table scan.
This patch skips disabled indexes for min/max optimization.
schemas
The function check_one_table_access() called to check access to tables in
SELECT/INSERT/UPDATE was doing additional checks/modifications that don't hold
in the context of setup_tables_and_check_access().
That's why the check_one_table() was split into two : the functionality needed by
setup_tables_and_check_access() into check_single_table_access() and the rest of
the functionality stays in check_one_table_access() that is made to call the new
check_single_table_access() function.
function crashes server".
Attempts to execute prepared multi-delete statement which involved trigger or
stored function caused server crashes (the same happened for such statements
included in stored procedures in cases when one tried to execute them more
than once).
The problem was caused by yet another incorrect usage of check_table_access()
routine (the latter assumes that table list which it gets as argument
corresponds to value LEX::query_tables_own_last). We solve this problem by
juggling with LEX::query_tables_own_last value when we call
check_table_access() for LEX::auxilliary_table_list (better solution is too
intrusive and should be done in 5.1).
Added test case for bug#18759 Incorrect string to numeric conversion.
select.test:
Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
Cleanup after fix for bug#18360 removal
Fixes bug#17264, for alter table on win32 for successfull operation completion
it is used TL_WRITE(=10) lock instead of TL_WRITE_ALLOW_READ(=6), however here
in innodb handler TL_WRTIE is lifted to TL_WRITE_ALLOW_WRITE, which causes
race condition when several clients do alter table simultaneously.
