There were no implementations for the virtual functions
exclusive_dependence_on_table_processor and
exclusive_dependence_on_table_processor. As a result
the procedure pushdown_cond_for_derived erroneously
detected some conditions with outer references as pushable
into materialized view / derived table.
.. (MDL_key::TABLE, table->db, table->table_name, MDL_SHARED)'
failed in mysql_rm_table_no_locks
Reset error flag after temporary table has been
successfully dropped.
- Replace #!/bin/bash with #!/bin/sh
- Split username:password using POSIX compat %% and ##
- Don't use array for FILTERS
- Replace == tests with POSIX-compat =
The idea of this fix was taken from the patch by Roy Lyseng
for mysql-5.6 bug iBug#14740889: "Wrong result for aggregate
functions when executing query through cursor".
Here's Roy's comment for his patch:
"
The problem was that a grouped query did not behave properly when
executed using a cursor. On further inspection, the query used one
intermediate temporary table for the grouping.
Then, Select_materialize::send_result_set_metadata created a temporary
table for storing the query result. Notice that get_unit_column_types()
is used to retrieve column meta-data for the query. The items contained
in this list are later modified so that their result_field points to
the row buffer of the materialized temporary table for the cursor.
But prior to this, these result_field objects have been prepared for
use in the grouping operation, by JOIN::make_tmp_tables_info(), hence
the grouping operation operates on wrong column buffers.
The problem is solved by using the list JOIN::fields when copying data
to the materialized table. This list is set by JOIN::make_tmp_tables_info()
and points to the columns of the last intermediate temporary table of
the executed query. For a UNION, it points to the temporary table
that is the result of the UNION query.
Notice that we have to assign a value to ::fields early in JOIN::optimize()
in case the optimization shortcuts due to a const plan detection.
A more optimal solution might be to avoid creating the final temporary
table when the query result is already stored in a temporary table.
"
The patch does not contain a test case, but the description of the
problem corresponds exactly what could be observed in the test
case for mdev-11081.
The motivation for this is that Perl is moving towards not having
current directory ./ in @INC by default. This is causing
mysql-test-run.pl to fail in latest Debian Unstable:
https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html
However, we have `use "lib"`, there is no need for current directory
in @INC, except for a gross hack. In mtr_cases.pm, there is a
`require "mtr_misc.pl"`, which hides mtr_misc.pl away in mtr_cases
namespace. And things only work because mysql-test-run.pl loads it
with a different name, `require "lib/mtr_misc.pl"`! (Perl will
`require` only once for each unique filename).
Fix this by only using `require` in main program, and referencing
functions with :: scope from other namespaces. For multi-use in
different namespaces, proper `use` modules should be used.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
In Debian many existing applications in Debian/Ubuntu have been built
while libmariadbclient-dev or libmariadbclient-dev-compat was installed.
To satisfy installation dependencies, the package name libmariadbclient18
must be provided, and at runtime a shared library must by the name
libmariadbclient.so.18.
Provide these to remain backwards compatible.
The new library name libmariadb3 matches the libmariadb.so.3 filename.
Packages that want to build against MariaDB Connector C have as
build-dependency libmariadb-dev and as run-time dependency libmariadb3.
Make the package provide libmariadbclient18 for backwards compatibility,
though compatibility is not always assured. There library did change
to a whole new generation after all, even though ABI compatibility has
been a design goal.
Also do the equivalent change for the -dev package. Packages that
explicitly want to use the MariaDB Connector C should mark it as
their build-depends.
Also provide an empty libmariadbclient18 metapackage to facilitate
upgrades from old MariaDB installs, just like there is an empty
libmysqlclient18 package. Create more of these in the future as needed.
Since Debian 9 (Stretch) and Ubuntu 16.10 (Yakkety) the following
packages have existed:
* virtual-mysql-client
* virtual-mysql-client-core
* virtual-mysql-server
* virtual-mysql-server-core
* virtual-libmysqlclient-dev
They are metapackages that in Debian depend on MariaDB and in
Ubuntu currently on MySQL. We need to provide them and point
them to MariaDB so that systems that have the mariadb.org
repositories enabled automatically get everything MariaDB
and not MySQL.
This change makes the packaging provide the four first ones,
and later commits will fix the client library issues.
The reason is that selecting from events_waits_history_long creates
a race condition: it can happen that SHOW EXPLAIN thread was kicked
off CPU exactly after posting a SHOW EXPLAIN request and then it wont
need to wait.
It doesn't seem to make sense to add more waits to stabilize the testcase.
Let's instead make a check that SHOW EXPLAIN statement has a
"stage/sql/show explain" stage.
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.
