Removing DBUG_DUMP printouts for valgrind builds since they trigger warnings.
Removing valgrind memory checks completely.
Removing bzero() of record when opening table that was added earlier.
Adding class to handle temporary allocate of memory during write of rows.
Eliminating cut'n-paste error between THD::binlog_{write,update,delete}_row().
It's not possible to flush the global status variables in 5.0
Update test case so it works by recording the value of handle_rollback
before and compare it to the value after
- As a sideeffect of the patch to generate lex_hash.h only once
on the machine where the source dist was produced, a problem
was found when compiling a mysqld without partition support - it
would crash when looking up the lex symbols due to mismatch between
lex.h and the generated lex_hash.h
- Remove the ifdef for partition in lex.h
- Fix minor problem with"EXPLAIN PARTITION" when not compiled with
partition(existed also without the above patch)
- Add test case that will be run when we don't have partition
support compiled into mysqld
- Return error ER_FEATURE_DISABLED if user tries to use PARTITION
when there is no support for it.
The value taken to be shown in SHOW PROCESSLIST is not
initialized when THD is created and will be random for
unauthenticated connections.
To the documentor: Random value, instead of NULL, was shown,
in SHOW PROCESSLIST for still non-authenticated connections.
The value taken to be shown in SHOW PROCESSLIST is not
initialized when THD is created and will be random for
unauthenticated connections.
To the documentor: Random value, instead of NULL, was shown,
in SHOW PROCESSLIST for still non-authenticated connections.
invocations of LAST_INSERT_ID.
Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
and no LAST_INSERT_ID_EVENT was issued for binary log.
The solution is to add THD::last_insert_id_used_bin_log, which is much
like THD::last_insert_id_used, but is reset only for upper-level
statements. This new variable is used to issue LAST_INSERT_ID_EVENT.
Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.
The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).
The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.
Version 5.1 does not have this bug (it was fixed by WL 3146).
(as part of the auto_increment cleanup of WL#3146; let's not be
sad, that monster push still removed serious bugs):
one problem with INSERT DELAYED (unexpected interval releases),
one with stored functions (wrong auto_inc binlogging).
These bugs were not released.
used.
Sorting by RAND() uses a temporary table in order to get a correct results.
User defined variable was set during filling the temporary table and later
on it is substituted for its value from the temporary table. Due to this
it contains the last value stored in the temporary table.
Now if the result_field is set for the Item_func_set_user_var object it
updates variable from the result_field value when being sent to a client.
The Item_func_set_user_var::check() now accepts a use_result_field
parameter. Depending on its value the result_field or the args[0] is used
to get current value.
There were two problems: RESET QUERY CACHE took a long time to complete
and other threads were blocked during this time.
The patch does three things:
1 fixes a bug with improper use of test-lock-test_again technique.
AKA Double-Checked Locking is applicable here only in few places.
2 Somewhat improves performance of RESET QUERY CACHE.
Do my_hash_reset() instead of deleting elements one by one. Note
however that the slowdown also happens when inserting into sorted
list of free blocks, should be rewritten using balanced tree.
3 Makes RESET QUERY CACHE non-blocking.
The patch adjusts the locking protocol of the query cache in the
following way: it introduces a flag flush_in_progress, which is
set when Query_cache::flush_cache() is in progress. This call
sets the flag on enter, and then releases the lock. Every other
call is able to acquire the lock, but does nothing if
flush_in_progress is set (as if the query cache is disabled).
The only exception is the concurrent calls to
Query_cache::flush_cache(), that are blocked until the flush is
over. When leaving Query_cache::flush_cache(), the lock is
acquired and the flag is reset, and one thread waiting on
Query_cache::flush_cache() (if any) is notified that it may
proceed.
- Make the range-et-al optimizer produce E(#table records after table
condition is applied),
- Make the join optimizer use this value,
- Add "filtered" column to EXPLAIN EXTENDED to show
fraction of records left after table condition is applied
- Adjust test results, add comments
"real" table fails in JOINs".
This is a regression caused by the fix for Bug 18444.
This fix removed the assignment of empty_c_string to table->db performed
in add_table_to_list, as neither me nor anyone else knew what it was
there for. Now we know it and it's covered with tests: the only case
when a table database name can be empty is when the table is a derived
table. The fix puts the assignment back but makes it a bit more explicit.
Additionally, finally drop sp.result.orig which was checked in by mistake.
