asserts.
The patch for Bug#21074 replaces acquisition of the global LOCK_open lock
with exclusive locks on table names in such operations ad DROP TABLE
and RENAME TABLE.
Unfortunately, NDB internally assumes that LOCK_open is acquired and
tries to release it.
This dependency should be fixed by a separate (and significant in size)
patch. For now we just satisfy it - after all, the original
goal of the patch for Bug#21074 was to move query_cache_invalidate
outside of the scope of LOCK_open, and we still can do that.
This fixes some failing NDB tests in the runtime tree.
The get_time_value function is added. It is used to obtain TIME values both
from items the can return time as an integer and from items that can return
time only as a string.
The Arg_comparator::compare_datetime function now uses pointer to a getter
function to obtain values to compare. Now this function is also used for
comparison of TIME values.
The get_value_func variable is added to the Arg_comparator class.
It points to a getter function for the DATE/DATETIME/TIME comparator.
results.
When executing a CREATE EVENT statement with ON COMPLETION NOT PRESERVE
clause (explicit or implicit) and completion date in the past, we do not
create the event. Or, put it differently, we create it and then drop
immediately.
A warning is issued in this case, not an error -- we want to load
successfully old database dumps, and such dumps may contain events
that are no longer valid.
Update the warning text to not imply an erroneous condition.
The Field_newdate::store when storing a DATETIME value was returning the
'value was cut' error even if the thd->count_cuted_fields flag is set to
CHECK_FIELD_IGNORE. This made range optimizr think that there is no
appropriate data in the table and thus to return an empty set.
Now the Field_newdate::store function returns conversion error only if the
thd->count_cuted_fields flag isn't set to CHECK_FIELD_IGNORE.
pseudo_thread_id was reset to zero via mysql_change_user() handling
whereas there is no reason to do that. Moreover, having two
concurrent threads that change user and create a namesake temp tables
leads to recording the dup pair of queries:
set @@session.pseudo_thread_id = 0;
CREATE temporary table `the namesake`;
which will stall the slave as the second instance can not be created.
And that is the bug case.
Fixed by correcting pseudo_thread_id value after mysql_change_user().
we now have exclusive name lock on the table name in mysql_rm_table_part2,
we still should keep LOCK_open - some storage engines are not
ready for locking scope change and assume that LOCK_open is kept.
Still, the binary logging and query cache invalidation calls
moved out of LOCK_open scope.
Fixes some of the broken 5.1-runtime tests (tests break on asserts).
gettimeofday() can fail and presumably, so can time().
Keep an eye on it.
Since we have no data on this at all so far, we just
retry on failure (and log the event), assuming that
this is just an intermittant failure. This might of
course hang the threat until we succeed. Once we know
more about these failures, an appropriate more clever
scheme may be picked (only try so many times per thread,
etc., if that fails, return last "good" time() we got or
some such). Using sql_print_information() to log as this
probably only occurs in high load scenarios where the debug-
trace likely is disabled (or might interfere with testing
the effect). No test-case as this is a non-deterministic
issue.
incomplete in 5.0 (and review fixes).
When in 5.0.13 I introduced class Prepared_statement and methods
::prepare and ::execute, general logging was left out of this class.
This was good for stored procedures, since in stored procedures
we do not log sub-statements, but introduced a regression in case of SQL
syntax for prepared statements, as previously we would log the actual
statements to the log, and after the change we would log only
COM_QUERY text.
Restore the old behavior, but still suppress logging if inside a stored
procedure.
Based on a community contributed patch from Vladimir Shebordaev.
No test case since we do not have a mechanism to test output
of the general log.
Time values were compared by the BETWEEN function as strings. This led to a
wrong result in cases when some of arguments are less than 100 hours and other
are greater.
Now if all 3 arguments of the BETWEEN function are of the TIME type then
they are compared as integers.
causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table
will block on X lock unnecessarily (duplciate).
Code review fixes.
Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently,
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table.
If a user had an InnoDB table, and two triggers, AFTER UPDATE and
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently.
The problem had other side-effects (see respective bug reports).
This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.
The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.
causing wrong error message in Falcon
An error message about a duplicate key could show a wrong key
value when not all columns of the key were used to select the
rows for update.
Some storage engines return a record with only the selected
columns filled.
This is fixed by re-reading the record with a read_set which
includes all columns of the duplicate key after a duplicate key
error happens and before the error message is printed.
