When CHANGE MASTER fails, it may or may not have already added
the Master_info * to the index. Implement logic that properly
handles removal and freeing in both cases.
storage/cassandra/CMakeLists.txt:
more thourough CHECK_CXX_SOURCE_COMPILES test, that checks whether
boost::shared_ptr can work with --fno-rtti
don't install anything in INSTALL_SYSCONFDIR, if the latter is unset
from MariaDB 10.0.
The bug in mdev-3948 was an instance of the problem fixed by Sergey's patch
in 10.0 - namely that the range optimizer could change table->[read | write]_set,
and not restore it.
revno: 3471
committer: Sergey Petrunya <psergey@askmonty.org>
branch nick: 10.0-serg-fix-imerge
timestamp: Sat 2012-11-03 12:24:36 +0400
message:
# MDEV-3817: Wrong result with index_merge+index_merge_intersection, InnoDB table, join, AND and OR conditions
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.
The problem was that a temporary table was re-created as a non-temporary table.
mysql-test/suite/maria/truncate.result:
Added test cases
mysql-test/suite/maria/truncate.test:
Added test cases
sql/sql_truncate.cc:
Mark that table to be created is a temporary table
storage/maria/ha_maria.cc:
Ensure that temporary tables are not transactional.
Miscellaneous workarounds for drop-in compatibility problems with Linux distributions, arounf versioning of the
MySQL 5.5 client shared library. There seems to be 3 different ways major distributions handle versioning
1. Fedora (also Mageia, and likely other Redhat descendants) way
old, 5.1 API functions are given version libmysqlclient_16
new API functions (client plugins, mysql_stmt_next ) are given version libmysqlclient_18
some extra functions beyond API are exported.
some functions are renamed.
2.Debian Wheezy way
all functions are given libmysqlclient_18 version
3. Ubuntu way (or MySQL/MariaDB download packages)
no versioning
UIp to this fix, MariaDB distributions did not have any versioning in the libraries, this rendered client library incompatible to distributions
thus exchanging distribution's libmysqlclient.so.18.0.0 with MariaDB's did not work nicely (anywhere but on Ubuntu)
THE FIX
is to build libraries the same way as distributions do it
- when building RPMs, use same version script as Fedora does, Make sure to export extra-symbols, the same as Fedora exports.
- when building DEBs, use the same version script as Debian Wheezy
- do not use version scripts otherwise
Also, makes sure that extensions of MySQL APIs (asynchronous client functionality) is exported by the shared libraries.
reached by fix_fields() (via reference) before row which it belongs to (on the second execution)
and fix_field for row did not follow usual protocol for Items with argument
(first check that the item fixed then call fix_fields).
Item_row::fix_field fixed.
