- Fix bug in bootstrapper.
- Also, delete innodb log files cafter bootstrapping , to workaround
"different log size" Innodb error during the first service start by MSI.
This is a temporary measure, in the future innodb will allow handling
different file size more gracefully.
The reason for the error is missing definition for SIGNAL_WITH_IO_CLOSE on this platform
which now needs to always be defined, as in 5.6
On Solaris10 only, this preprocessor constant was not defined, thus code that shutdowns a socket in THD::awake was not executed, and polling thread was not interrupted.
Fix is to always define SIGNAL_WITH_IO_CLOSE, just like MySQL5.6 does.
Fix mismerged code from 5.6 (named-pipe related). viopipe.c, which was introduced in 5.6 is now copied almost identically into 10.0
The unused vio::pipe_overlapped is removed.
MDEV-567: Wrong result from a query with correlated subquery if ICP is allowed:
backport the fix developed for SHOW EXPLAIN:
revision-id: psergey@askmonty.org-20120719115219-212cxmm6qvf0wlrb
branch nick: 5.5-show-explain-r21
timestamp: Thu 2012-07-19 15:52:19 +0400
BUG#992942 & MDEV-325: Pre-liminary commit for testing
and adjust it so that it handles DS-MRR scans correctly.
Reconcile the fixes from:
#
# guilhem.bichot@oracle.com-20110805143029-ywrzuz15uzgontr0
# Fix for BUG#12698916 - "JOIN QUERY GIVES WRONG RESULT AT 2ND EXEC. OR
# AFTER FLUSH TABLES [-INT VS NULL]"
#
# guilhem.bichot@oracle.com-20111209150650-tzx3ldzxe1yfwji6
# Fix for BUG#12912171 - ASSERTION FAILED: QUICK->HEAD->READ_SET == SAVE_READ_SET
# and
#
and related fixes from: BUG#1006164, MDEV-376:
Now, ROR-merged QUICK_RANGE_SELECT objects make no assumptions about the values
of table->read_set and table->write_set.
Each QUICK_ROR_SELECT has (and had before) its own column bitmap, but now, all
QUICK_ROR_SELECT's functions that care: reset(), init_ror_merged_scan(), and
get_next() will set table->read_set when invoked and restore it back to what
it was before the call before they return.
This allows to avoid the mess when somebody else modifies table->read_set for
some reason.
Use post_kill_notification in for one_thread_per_connection scheduler,
the same as already used in threadpool, to reliably wake a thread stuck in
read() or in different poll() variations.
- Ensure asm parameters are in registers, so we do not de-reference from
bogus stack pointer.
- Make return address undefined in DWARF unwind info in my_context_spawn,
so DWARF-based unwinders will know this is the end of the call stack
(same as the amd64 fix for the similar issue).
Changed implementation os_file_rename() on Windows such as it does not fail if destination file already exists. Now MoveFileEx() with MOVEFILE_REPLACE_EXISTING flag is used, instead of prior MoveFile().
This fixed implementation is better compatible with rename() on POSIX systems.
(and collateral changes)
mysql-test/t/innodb_mysql_lock.test:
change the variable from the test, not from the .opt file.
one mysqld restart less.
mysql-test/t/lowercase_table4.test:
fix dos line endings
sql/handler.cc:
don't access the uninitialized variable
Ensure semicolons are not lost when concatenating fill_help_tables to bootstrap.sql in Windows.
5.6 bootstrapper requires semicolons to separate bootstrapper commands.
always use intptr type when casting a pointer to an integer to avoid sign expansion.
or, at least, cast identically in socket_summary_by_instance and socket_instances
The following piece of code in trnman.c:
345 trn->min_read_from= active_list_min.next->trid;
...
351 active_list_max.prev= trn->prev->next= trn;
352 trid_min_read_from= active_list_min.next->min_read_from;
on 345 gcc stores active_list_min.next in %ebx
(and trn->min_read_from=[%ebx]->trid)
and on 352 it does trid_min_read_from= [%ebx]->min_read_from;
BUT active_list_min.next was changed on the line 351.
gcc doesn't notice it and continues to use the cached value.
This task fixes an ineffeciency that is a remainder from MySQL 5.0/5.1. There, subqueries
were optimized in a lazy manner, when executed for the first time. During this lazy optimization
it may happen that the server finds a more efficient subquery engine, and substitute the current
engine of the query being executed with the new engine. This required re-execution of the engine.
MariaDB 5.3 pre-optimizes subqueries in almost all cases, and the engine is chosen in most cases,
except when subquery materialization found that it must use partial matching. In this case, the
current code was performing one extra re-execution although it was not needed at all. The patch
performs the re-execution only if the engine was changed while executing.
In addition the patch performs small cleanup by removing "enum store_key_result" because it is
essentially a boolean, and the code that uses it already maps it to a boolean.
