This is a post-review patch.
Fixes the typelib implementation, available only in 5.1.11.
--event-scheduler cmdline : DISABLED | ON | OFF | 0 | 1
DISABLED - makes the scheduler unavailable during the server run
(ON|1)- When the server is started the scheduler will be started. It can
be stopped and restarted by setting appropriate values to
GLOBAL event_scheduler
(OFF|0)- When the server is started, the scheduler won't be started. It
can be started and again stopped by setting appropriate values to
GLOBAL event_scheduler. _DEFAULT_ value
The GLOBAL variable event_scheduler can have the following values:
OFF | ON | 0 | 1
DISABLED is not possible and every attempt will end with an error that
it's not a valid value for the variable.
OFF | 0 - This is the pre-5.1.11 behavior - The scheduler stops, if not
already stopped, and can be started again by setting
the value of the variable to ON|1.
ON | 1 - This is the pre-5.1.11 behavior - The scheduler starts, if not
already started, and can be stopped again by setting the value
of the variable to OFF|0.
This patch makes the relationship between Event_scheduler and Event_queue
unidirectional from the former to the latter.
The change is that the conditional on which the scheduler sleeped has been
moved to the Event_queue and the latter does not call anymore
Event_scheduler::queue_changed(), which in turn has be removed.
doesn't find the column"
When a user was using 4.1 tables with VARCHAR column and 5.0 server
and a query that used a temporary table to resolve itself, the
table metadata for the varchar column sent to client was incorrect:
MYSQL_FIELD::table member was empty.
The bug was caused by implicit "upgrade" from old VARCHAR to new
VARCHAR hard-coded in Field::new_field, which did not preserve
the information about the original table. Thus, the field metadata
of the "upgraded" field pointed to an auxiliary temporary table
created for query execution.
The fix is to copy the pointer to the original table to the new field.
When a view was used inside a trigger or a function, lock type for
tables used in a view was always set to READ (thus making the view
non-updatable), even if we were trying to update the view.
The solution is to set lock type properly.
erroneous check
Problem: Actually there were two problems in the server code. The check
for SQLCOM_FLUSH in SF/Triggers were not according to the existing
architecture which uses sp_get_flags_for_command() from sp_head.cc .
This function was also missing a check for SQLCOM_FLUSH which has a
problem combined with prelocking. This changeset fixes both of these
deficiencies as well as the erroneous check in
sp_head::is_not_allowed_in_function() which was a copy&paste error.
const tables. This resulted in choosing extremely inefficient
execution plans in same cases when distribution of data in
joined were skewed (see the customer test case for the bug).
The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;
Actually there is no recursive call but the limit is checked.
Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.
