MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))

Different fix. Don't allow Item_func_sp to be evaluated unless
all tables are prelocked.

Extend the test case to make sure Item_func_sp::val_str is called
(the table must have at least one row for that).

Revert "MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))"

This reverts commit 035a5ac6.

Two minor problems and one regression:
1. caching the value in str_result. Other Item methods may use it,
   destroying the cache. See, for example, Item::save_in_field, where
   str_result is moved to use a local buffer (this failed main.grant)
2. Item_func_conv_charset::safe is now set too late, it's initialized
   only in val_str() but checked before that, this failed many tests
   in optimized builds.

to fix 1 - use tmp_result instead of str_result, to fix 2, use
the else branch in the Item_func_conv_charset constructor to set
safe purely from charset properties.

But this introduces a regression, constant strings can no longer be
converted, say, from utf8 to latin1 (because 'safe' will be false).
This fails few tests too. There is no way to fix it without reverting
the commit and converting constants, as before, in the constructor.

MDEV-11162 Assertion `num_records == m_idx_array.size()' failed in Filesort_buffer::alloc_sort_buffer(uint, uint)

Updating result for the group_by_innodb.test

MDEV-11162 Assertion `num_records == m_idx_array.size()' failed in Filesort_buffer::alloc_sort_buffer(uint, uint)

When JOIN::destroy() is called for a JOIN object that has
   - join->tmp_join != NULL
   - also has join->table[0]->sort

then the latter was not cleaned up.
This could cause a memory leak and/or asserts in the subsequent queries.

Fixed by adding a cleanup call.

truncate unused IO_CACHE backing store files in binlog_cache_data
to release the disk space they were occupying

        Rpl_filter::parse_filter_rule() made NULL-safe.

Update mysqldump man page

check for VIEW/DERIVED fields

MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))

Move expression execution out of Item constructor.

Exclude untouched in prepare phese subqueries from the select/unit tree
because they became unreachable by execution.

The problem was that null_value was not set to "false" on a well-formed row.
If an ill-formed row was followed by a well-forned row, null_value remained
"true" in the call of Item::send() for the well-formed row.

Check for readline before checking for curses headers, because
MYSQL_CHECK_READLINE fails when curses is not found, but
CHECK_INCLUDE_FILES simply remembers the fact and continues.  So if
there's no curses, MYSQL_CHECK_READLINE will abort, the user will then
installs curses and continue the build. Thus, CHECK_INCLUDE_HEADERS
will remember that there is no curses, but other checks from
MYSQL_CHECK_READLINE will remember that curses are there. It will
result in inconsistent HAVE_xxx defines.

be consistent and don't include the table name into the error message,
no other CREATE TABLE error does it.

(the crash happened, because thd->lex->query_tables was NULL)

Don't assume that a word of n bytes can match a word of
at most n * charset->mbmaxlen bytes, always go for the worst.

Due to the collation used on the roles_mapping_hash, key comparison
would work in a case-insensitive manner. This is incorrect from the
roles mapping perspective. Make use of a case-sensitive collation for that hash,
the same one used for the acl_roles hash.

The function Item_func_isnull::update_used_tables() must
handle the case when the predicate is over not nullable
column in a special way.
This is actually a bug of MariaDB 5.3/5.5, but it's probably
hard to demonstrate that it can cause problems there.

Test intentionally crashes the server, thus corrupted pages possible.

MDEV-11343 LOAD DATA INFILE fails to load data with an escape character followed by a multi-byte character

Partially backporting MDEV-9874 from 10.2 to 10.0

READ_INFO::read_field() raised the ER_INVALID_CHARACTER_STRING error
when reading an escape character followed by a multi-byte character.

Raising wellformedness errors in READ_INFO::read_field() was wrong,
because the main goal of READ_INFO::read_field() is to *unescape* the
data which was presumably escaped using mysql_real_escape_string(),
using the same character set with the one specified in
"LOAD DATA INFILE ... CHARACTER SET ..." (or assumed by default).

During LOAD DATA, multi-byte characters are not always scanned as a single
entity! In case of escaped data, parts of a multi-byte character can be
scanned on different loop iterations. So the old code erroneously tested
welformedness in the middle of a multi-byte character.

Moreover, the data after unescaping can go into a BLOB field, not a text field.
Wellformedness tests are meaningless in this case.

Ater this patch, wellformedness is only checked later, during
Field::store(str,length,cs) time. The loop that scans bytes only
makes sure to revert the changes made by mysql_real_escape_string().

Note, in some cases users can supply data which did not really go through
mysql_real_escape_string() and was escaped by some other means,
or was not escaped at all. The file reported in this MDEV contains
the string "\ä", which is an example of such improperly escaped data, as
- either there should be two backslashes:   "\\ä"
- or there should be no backslashes at all: "ä"
mysql_real_escape_string() could not generate "\ä".

MDEV-11171 Assertion `m_cpp_buf <= ptr && ptr <= m_cpp_buf + m_buf_length' failed in Lex_input_stream::body_utf8_append(const char*, const char*)

MDEV-11348 LOAD DATA LOCAL INFILE crashes the server on loading a backslash followed by a multi-byte character

The crash happened when if my_error() was called for any reasons during loading
(e.g. a bad multi-byte sequence or a bad GEOMETRY value was found).
The server sent both error and progress packets, so the client disconnected.
The server then crashed on a assert about a wrong packet order in Debug build.
The server also tried to read from a closed socket when calling
READ_INFO::skip_data_till_eof().

As the crash happened only with "mysql" running in interactive mode,
no tests are possible. The problem was not reproducible with
"mysqltest" or "mysql" in batch mode.

This is not a fix, this is instrumentation to find out is MySQL frm dictionary
and InnoDB data dictionary really out-of-sync when this assertion is fired,
or is there some other reason (bug).

Fixing the "connect" command to use "localhost" instead of "127.0.0.1"
to make it work with both "mtr" and "mtr --embedded".

The SQL thread keeps track of the position in the current relay log from
which to read the next event. This position is not normally used, but a
certain interaction with the IO thread can cause the SQL thread to re-open
the relay log and seek to the stored position.

In parallel replication, there were a couple of places where the position
was not updated. This created a race where a re-open of the relay log could
seek to the wrong position and start re-reading and processing events
already handled once, causing various kinds of problems.

Fix this by moving the position update into a single place in
apply_event_and_update_pos(), which should ensure that the position is
always updated in the parallel replication case.

This problem was found from the testcase of MDEV-10863, but it is logically
a separate problem.

This has no functional changes, but it helps avoid merge problems from 10.0
to 10.1. In 10.0, code that checks for parallel replication uses
opt_slave_parallel_threads > 0, but this check needs to be
mi->using_parallel() in 10.1. By using the same check in 10.0 (with
unchanged semantics), merge problems to 10.1 are avoided.

The flag TABLE_LIST::fill_me must be reset to false at the prepare
phase for any materialized derived table used in the executed query.
Otherwise if the optimizer decides to generate a key for such a table
it is generated only for the first execution of the query.