Due to high memory reqirements spider tests fail often on automated testing
VM's due to rather limited resource allocation.
For example with 10.2 spider needs at least 200M * 8 mysqld instances = 1.6Gb
RAM per mtr instance. With --parallel=4 it needs 6.4Gb, while appropriate hosts
have just 3Gb.
libmariadbd19 was intended to be added as the package that
included the libmysqld shared library. This was missing
from the debian control file.
The libmariadbd-dev package requires libmariadbd19 to provide
the shared library.
The shared libraries for embedded mysql will go into the libmariadbd18
package rather than the libmariadbd-dev development package.
/usr/bin/mariadb_config is a executable that assists embedded developers
to use the correctly correct header and library files during their
development.
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>
Previously private/*.h where included in the package. These represent internal
mysqld structures that aren't guarenteed to provide a stable ABI.
There aren't intended to be used by embedded mysqld applications so
they have been removed.
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>
The class Item_func_nop_all missed an implementation
of the virtual method get_copy.
As a result if the condition that can be pushed into
into a materialized view / derived table contained
an ANY subselect then the pushdown condition was built
incorrectly.
Problem was that test assumes locks to be granted on first-come-first-served (FCFS)
policy. However, in 10.2 we use by default Variance-Aware-Transaction-Scheduling
(VATS) algorithm. Test failure fixed by setting lock wait policy to FCFS.
In a general case the conditions with outer fields cannot
be pushed into materialized views / derived tables.
However if the outer field in the condition refers to a
single row table then the condition may be pushable.
In this case a special care should be taken for outer
fields when pushing the condition into a materialized view /
derived table.
During total-order replication, Query_log_event's checksum_alg
should be explicitly set to the current binlog_checksum as it
is not set for DML queries.
Note: wsrep_replicate_myisam enables replication of DMLs on
MyISAM tables using TOI.
When a BF thread attempts to abort a victim thread's transaction,
the victim thread is not locked and thus its not safe to rely on
its data structures like htons registered for the trx.
So, instead of getting the registered htons from victim, innodb's
hton can be looked up directly from installed_htons[] and used to
abort the transaction. (Same technique is used in older versions)
The crash is caused due to a race condition where wsrep
startup threads invoke ha_maria::implicit_commit() method
while maria_hton is partially initialized. The fix is to
skip this method if plugins are uninitialized.
The .rdiff applied ok locally with my copy of patch, but failed with
"misordered hunks" on a test host. Maybe that host has a more strict
version of `patch`.
With "WL#6047 - Do not allocate trx id for read-only transactions"
m_prebuilt->trx->id is always 0 for read-only transactions. This makes
it useless as an index for fuzzy counters.
Use server thread id instead similarly to MySQL.
BINLOG statement output by mysqlbinlog actually has the base64 of the
non-compressed event. So remove my previous incorrect review change,
which allowed compressed event types for BINLOG statement.
Also add a couple test cases for this, running mysqlbinlog | mysql.
for InnoDB tables"
Don't use thr_lock.c locks for InnoDB tables. Below is list of changes that
were needed to implement this:
- HANDLER OPEN acquireis MDL_SHARED_READ instead of MDL_SHARED
- HANDLER READ calls external_lock() even if SE is not going to be locked by
THR_LOCK
- InnoDB lock wait timeouts are now honored which are much shorter by default
than server lock wait timeouts (1 year vs 50 seconds)
- with @@autocommit= 1 LOCK TABLES disables autocommit implicitely, though
user still sees @@autocommt= 1
- the above starts implicit transaction
- transactions started by LOCK TABLES are now rolled back on disconnect
(previously everything was committed due to autocommit)
- transactions started by LOCK TABLES are now rolled back by ROLLBACK
(previously everything was committed due to autocommit)
- it is now impossible to change BINLOG_FORMAT under LOCK TABLES (at least
to statement) due to running transaction
- LOCK TABLES WRITE is additionally handled by MDL
- ...in contrast LOCK TABLES READ protection against DML is pure InnoDB
- combining transactional and non-transactional tables under LOCK TABLES
may cause rolled back changes in transactional table and "committed"
changes in non-transactional table
- user may disable innodb_table_locks, which will cause LOCK TABLES to be
noop basically
Removed tests for BUG#45143 and BUG#55930 which cover InnoDB + THR_LOCK. To
operate properly these tests require code flow to go through THR_LOCK debug
sync points, which is not the case after this patch. These tests are removed
by WL#6671 as well. An alternative is to port them to different storage engine.
Issue:
======
Currently the approach we take to find the chunk corresponding to a given
pointer uses srv_buf_pool_chunk_unit based on the assumption that
srv_buf_pool_chunk_unit is the total size of all pages in a buffer pool
chunk. We first step back by srv_buf_pool_chunk_unit bytes and use
std::map::upper_bound() to find the first chunk in the map whose key >= the
resulting pointer.
However, the real size of a chunk (and thus, the total size of its pages)
may differ from the value configured with innodb_buffer_pool_chunk_size
due to rounding up to the OS page size. So, in some cases the above logic
gives us the wrong chunk.
Fix:
====
We find out the chunk corresponding to the give pointer without using
srv_buf_pool_chunk_unit. This is done by using std::map::upper_bound()
to find the next chunk in the map which appears right after the pointer and
decrementing the iterator, which would give us the chunk the pointer
belongs to.
Contribution by Alexey Kopytov.
RB: 13347
Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com>
