fixes the following valgrind warning (when running ndb_mgm under valgrind,
or, indeed any other mgmapi program listening to events):
==23291== 190 (20 direct, 170 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 22
==23291== at 0x401C895: operator new(unsigned) (vg_replace_malloc.c:163)
==23291== by 0x8075300: ParserImpl::run(Parser<ParserImpl::Dummy>::Context*, Properties const**, bool volatile*) const (Parser.cpp:178)
==23291== by 0x806D09B: Parser<ParserDummy>::parse(Parser<ParserDummy>::Context&, ParserDummy&) (Parser.hpp:219)
==23291== by 0x80671C4: ndb_mgm_call(ndb_mgm_handle*, ParserRow<ParserDummy> const*, char const*, Properties const*) (mgmapi.cpp:355)
==23291== by 0x806AB79: ndb_mgm_listen_event_internal(ndb_mgm_handle*, int const*, int) (mgmapi.cpp:1419)
==23291== by 0x806AC1F: ndb_mgm_listen_event (mgmapi.cpp:1434)
==23291== by 0x805EB5D: event_thread_run(void*) (CommandInterpreter.cpp:467)
==23291== by 0x806F70A: ndb_thread_wrapper (NdbThread.c:68)
==23291== by 0x4042340: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so)
==23291== by 0x429D4ED: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
fix the following valgrind warning when running ndb_mgm -e show (leak only in client)
==20398== 14,596 (11,936 direct, 2,660 indirect) bytes in 4 blocks are definitely lost in loss record 24 of 25
==20398== at 0x401C4A1: malloc (vg_replace_malloc.c:149)
==20398== by 0x80797A3: ConfigValuesFactory::create(unsigned, unsigned) (ConfigValues.cpp:309)
==20398== by 0x8079F03: ConfigValuesFactory::expand(unsigned, unsigned) (ConfigValues.cpp:325)
==20398== by 0x8079967: ConfigValuesFactory::put(ConfigValues::Entry const&) (ConfigValues.cpp:414)
==20398== by 0x807A7B6: ConfigValuesFactory::unpack(void const*, unsigned) (ConfigValues.cpp:701)
==20398== by 0x806CB9D: ConfigValuesFactory::unpack(UtilBuffer const&) (ConfigValues.hpp:252)
==20398== by 0x8069160: ndb_mgm_get_configuration (mgmapi.cpp:1941)
==20398== by 0x8060661: CommandInterpreter::executeShow(char*) (CommandInterpreter.cpp:1242)
==20398== by 0x8063966: CommandInterpreter::execute_impl(char const*) (CommandInterpreter.cpp:715)
==20398== by 0x8064040: CommandInterpreter::execute(char const*, int, int*) (CommandInterpreter.cpp:625)
==20398== by 0x8064189: Ndb_mgmclient::execute(char const*, int, int*) (CommandInterpreter.cpp:203)
==20398== by 0x805E56C: read_and_execute(int) (main.cpp:124)
==20398== by 0x805E754: main (main.cpp:162)
==20398==
SELECT right instead of INSERT right was required for an insert into to a view.
This wrong behaviour appeared after the fix for bug #20989. Its intention was
to ask only SELECT right for all tables except the very first for a complex
INSERT query. But that patch has done it in a wrong way and lead to asking
a wrong access right for an insert into a view.
The setup_tables_and_check_access() function now accepts two want_access
parameters. One will be used for the first table and the second for other
tables.
In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)"
where N>1000, was incorrectly converted to
(-inf < X < c_min) OR (c_max < X)
Now this conversion is removed, we dont produce any range lists for such
conditions.
This bug is a side-effect of bug fix#16377. NOW() is optimized in
BETWEEN to integer constants to speed up query execution. When view is being
created it saves already modified query and thus becomes wrong.
The agg_cmp_type() function now substitutes constant result DATE/TIME functions
for their results only if the current query isn't CREATE VIEW or SHOW CREATE
VIEW.
Zero-length variables caused failures when using the length to look
up the name in a hash. Instead, signal that no zero-length name can
ever be found and that to encounter one is a syntax error.
The crash was caused by invalid sequence of handler::** calls:
ha_smth->index_init();
ha_smth->index_next_same(); (2)
(2) is an invalid call as it was not preceeded by any 'scan setup' call
like index_first() or index_read(). The cause was that QUICK_SELECT::reset()
didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten,
and quick select might attempt to continue reading the range, which would
result in the above mentioned invalid sequence of handler calls.
5.x versions are not affected by the bug - they already have the missing
"range=NULL" clause.
bug #18184 SELECT ... FOR UPDATE does not work..: New test case
ha_ndbcluster.h, ha_ndbcluster.cc, NdbConnection.hpp:
Fix for bug #21059 Server crashes on join query with large dataset with NDB tables: Releasing operation for each intermediate batch, before next call to trans->execute(NoCommit);
- if there are two character set definitions in the column declaration,
we replace the first one with the second one as we store both in the LEX->charset
slot. Add a separate slot to the LEX structure to store underscore charset.
- convert default values to the column charset of STRING, VARSTRING fields
if necessary as well.
Disable const propagation for Item_hex_string.
This must be done because Item_hex_string->val_int() is not
the same as (Item_hex_string->val_str() in BINARY column)->val_int().
We cannot simply disable the replacement in a particular context (
e.g. <bin_col> = <int_col> AND <bin_col> = <hex_string>) since
Items don't know the context they are in and there are functions like
IF (<hex_string>, 'yes', 'no').
Note that this will disable some valid cases as well
(e.g. : <bin_col> = <hex_string> AND <bin_col2> = <bin_col>) but
there's no way to distinguish the valid cases without having the
Item's parent say something like : Item->set_context(Item::STRING_RESULT)
and have all the Items that contain other Items do that consistently.
