The function that checks whether we can use keys for aggregates,
find_key_for_maxmin(), assumes that keys disabled by ALTER TABLE
... DISABLE KEYS are not in the set table->keys_in_use_for_query.
I.E., if a key is in this set, the optimizer assumes it is free to
use it.
The bug is that keys disabled with ALTER TABLE ... DISABLE KEYS still
appear in table->keys_in_use_for_query When the TABLE object has been
initialized with setup_tables(). Before setup_tables is called, however,
keys that are disabled in the aforementioned way are not included in
TABLE::keys_in_use_for_query.
The provided patch changes the code that updates keys_is_use_for_query so
that it assumes that keys_is_use_for_query already takes into account all
disabled keys, and generally all keys that should be used by the query.
it can't be compile everywhere if we just cast pointer to pthread_t
So now we use correct pthread_self() value as the pthread_t and
pointer where we need to identify the thread exactly.
binlog_filter and rpl_filter are initialized in server's 'main' function
which doesn't work in the embedded server. So this code moved to
function working in both cases.
The build scripts in general, using automake, autoconf, etc, contain several
special commands and work around all related to the way the bison code in the
parser is built, for sql/sql_yacc.yy. These work arounds, accumulated over
time during development, ultimately cause the build scripts to be unstable
and cause build defects by not enforcing dependencies.
This fix simplifies the build process and aligns it with the automake tooling,
which provides native support for bison and *.yy files.
In particular, the following problem have been fixed:
- dependencies with sql_yacc.cc were not honored (Bug 21029), leading to
corrupted builds,
- the work around introduced by Bug 24557, to cleanup the generated files
sql_yacc.h and sql_yacc.cc, has been removed,
- the generated makefile, in a source distribution, used to destroy the files
sql_yacc.h and sql_yacc.cc on a 'make clean' target. This has been fixed:
these files are now removed by make maintainer-clean.
- The root cause of the problem found with gcc 4.1 (see Bug 24619) has been
clearly documented, and the "sed" hack has been replaced by a cleaner
work around, when building the code with bison 1.875.
- Removed the file sql/sql_yacc.yy.bak, added by WL 3031 by accident.
- Removed the unnecessary AM_YFLAG= --debug introduced by WL 3432, since
the compiling option DBUG_OFF takes precedence when setting YYDEBUG.
RAND() must accept scalar expressions regardless of their kind.
That includes both constant expressions and expressions that
depend on column values.
When the expression is constant the random seed can be initialized
at compile time.
However when the expression is not constant the random seed must be
initialized at each invocation (while it still can be allocated at
compile time).
Implemented the above rules by extending Item_func_rand::val_real()
to initialize the random seed at the correct place.
"Valgrind leak in closecon_handlerton"
plugin_shutdown() calls plugin_deinitialize() which calls ha_finalize_handlerton().
ndbcluster_end() fails to wait for the ndb utility thread to exit which results in
the handlerton struct being freed before the ndb utility thread has destroyed it's THD
but before the plugin has been marked as UNINITIALIZED
Bug is caused by misuse of abort_loops variable and not locking mutex during calls to
pthread condition variable functions causing a race in valgrind's pthread_cond_wait
implementation.
on duplicate key".
INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in
stored routine or as prepared statement and which in its ON DUPLICATE
KEY clause erroneously tried to assign value to a column mentioned only
in its SELECT part was properly emitting error on the first execution
but succeeded on the second and following executions.
Code which is responsible for name resolution of fields mentioned in
UPDATE clause (e.g. see select_insert::prepare()) modifies table list
and Name_resolution_context used in this process. It uses
Name_resolution_context_state::save_state/restore_state() to revert
these modifications. Unfortunately those two methods failed to revert
properly modifications to TABLE_LIST::next_name_resolution_table
and this broke name resolution process for successive executions.
This patch fixes Name_resolution_context_state::save_state/restore_state()
in such way that it properly handles TABLE_LIST::next_name_resolution_table.
When inserting into a join-based view the update fields from the ON DUPLICATE
KEY UPDATE wasn't checked to be from the table being inserted into and were
silently ignored.
The new check_view_single_update() function is added to check that
insert/update fields are being from the same single table of the view.
