ha_partition creates temporary ha_XXX objects for its partitions when
performing DDL operations. The objects were created on a MEM_ROOT and
never deleted.
This works as long as ha_XXX objects free all data ha_XXX::close() and
don't rely on a proper destructor invocation. Unfortunately, ha_rocksdb
includes String members which need to be delete'd properly.
Fixed the bug by having ha_partition::~ha_partition delete these temporary
objects.
modified: storage/connect/ha_connect.h
modified: storage/connect/ha_connect.cc
-- Trace work storage allocation and freeing in DEVELOPMENT mode
(Fix a compile error)
modified: storage/connect/plugutil.cpp
Make st_select_lex::set_explain_type() take into account that JOIN_TABs
it is traversing may be also post-join aggregation JOIN_TABs (which
have pos_in_table_list=NULL, etc).
Problem was that dict_sys->size tries to maintain used memory
occupied by the data dictionary table and index objects.
However at least on table objects table->heap size can increase
between when table object is inserted to dict_sys and when
it is removed from dict_sys causing inconsistency on amount
of memory added to and removed from dict_sys->size variable.
Removed unnecessary dict_sys:size variable as it is really
used only for status output.
Introduced dict_sys_get_size function to calculate memory
occupied by the data dictionary table and index objects
that is then used on show engine innodb output.
dict_table_add_to_cache(),
dict_table_rename_in_cache(),
dict_table_remove_from_cache_low(),
dict_index_remove_from_cache_low(),
Remove size calculation.
srv_printf_innodb_monitor(): Use dict_sys_get_size function to
get dictionary memory allocated.
xtradb_internal_hash_tables_fill_table(): Use dict_sys_get_size
function to get dictionary memory allocated.
Do not run the window function computation step when the select
produces no rows (zero_result_cause!=NULL).
This may cause reads from uninitialized memory.
We still need to run the window function computation step when
the output includes just one row (for example
SELECT MAX(col), RANK() OVER (...) FROM t1 WHERE 1=0).
This fix also resolves an issue with queries with window functions
producing an output row where should be none, like in
SELECT ROW_NUMBER() FROM t1 WHERE 1=0.
Updated a few test results in the existing tests to reflect this.
Backport of 7e29f2d64f from 10.1.
Create_field does not set BINARY_FLAG, so the check didn't work at all.
Also, character sets were already compared, so this check would've been
redundant (if it would've worked).
1. use Regexp_processor_pcre::set_recursion_limit() to set the
recursion limit depending on the current available stack size
2. make pcre stack frame to be estimated no less than 500 bytes.
sometimes pcre estimates it too low, even though the manual
says 500+16 bytes (it was estimated only 188 for me, actual
frame size was 512).
3. do it for embedded too
Change the semantics of thd_get_error_context_description().
It no longer expects the caller to lock LOCK_thread_count
(no caller ever did that anyway), but takes care of it internally.
Crashes with innodb_page_size=64K. Does not crash at <= 32K.
Problem was that when blob record that was earlier < 16k is
enlarged at update wo that length > 16K it should be stored
externally. However, that was not enforced when page-size = 64K
(note that 16K+1 < 64K/2 i.e. half of the btree leaf page).
btr_cur_optimistic_update: limit max record size to 16K
or in REDUNDANT row format to 16K-1.
Problem
rpl.rpl_mdev-11092 fails in buildbot because after starting slave in
wait_for_slave_sql_error_and_skip.inc slave is started but there may be
chances that we have not skipped the last error and Last_SQL_Errno is
still not zero untill the end of rpl_end.inc , which will compare
Last_SQL_Errno to 0. So in this this case rpl_mdev-11092 fails.
Solution
After starting slave in wait_for_slave_sql_error_and_skip.inc we will wait for
Last_SQL_Errno to become 0.
modified: storage/connect/connect.cc
modified: storage/connect/plugutil.cpp
modified: storage/connect/jsonudf.cpp
-- Update result from json_udf test
modified: storage/connect/mysql-test/connect/r/json_udf.result
end_io_call uses uninitialized values from the new_data_cache
As such we the buffer 0 and check this before calling end_io_cache on it.
Thanks Sergey Vojtovich for the review and for this solution.
Found by Coverity (ref 972481).
