Problem was that dict_sys->size tries to maintain used memory
occupied by the data dictionary table and index objects.
However at least on table objects table->heap size can increase
between when table object is inserted to dict_sys and when
it is removed from dict_sys causing inconsistency on amount
of memory added to and removed from dict_sys->size variable.

Removed unnecessary dict_sys:size variable as it is really
used only for status output.

Introduced dict_sys_get_size function to calculate memory
occupied by the data dictionary table and index objects
that is then used on show engine innodb output.

dict_table_add_to_cache(),
dict_table_rename_in_cache(),
dict_table_remove_from_cache_low(),
dict_index_remove_from_cache_low(),
	Remove size calculation.

srv_printf_innodb_monitor(): Use dict_sys_get_size function to
get dictionary memory allocated.

xtradb_internal_hash_tables_fill_table(): Use dict_sys_get_size
function to get dictionary memory allocated.

apparently it uses a smaller per-thread stack

Backport of 7e29f2d6 from 10.1.

Create_field does not set BINARY_FLAG, so the check didn't work at all.
Also, character sets were already compared, so this check would've been
redundant (if it would've worked).

InnoDB fix will come in MDEV-13360.
Here I just fix upgrades from old unfixed InnoDBs - bad data
makes the following copying ALTER TABLE to fail.

MDEV-13173 An RLIKE that previously worked on 10.0 now returns "Got error 'pcre_exec: recursion limit of 100 exceeded' from regexp"

1. use Regexp_processor_pcre::set_recursion_limit() to set the
   recursion limit depending on the current available stack size
2. make pcre stack frame to be estimated no less than 500 bytes.
   sometimes pcre estimates it too low, even though the manual
   says 500+16 bytes (it was estimated only 188 for me, actual
   frame size was 512).
3. do it for embedded too

Change the semantics of thd_get_error_context_description().
It no longer expects the caller to lock LOCK_thread_count
(no caller ever did that anyway), but takes care of it internally.

Increased size in tests to allow for 100 character hostname.
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

        In get_mm_tree we have to change Field_geom::geom_type to
        GEOMETRY as we have to let storing all types of the spatial features
        in the field. So now we restore the original geom_type as it's
        done.

(10.0+ changes, as specified in the MDEV)

and remove unused variable (compiler warning)

MDEV-10146: Wrong result (or questionable result and behavior) with aggregate function in uncorrelated SELECT subquery

When outer reference resolved in a VIEW it still should mark aggregate function resolving border.

Found by Coverity (id 971843).
Signed-off-by: Daniel Black <daniel.black@au.ibm.com>

make_lock_and_pin didn't release the lock so we should.

Found by Coverity (id 972095).

Release the lock for the error path.

Found by Coverity (id 972093).

translog_stop_writing doesn't release a lock (though
does to a DBUG_ASSERT).

Better to just release the lock.

Found by Coverity id 972092

Found by Coverity scan - id 92087

max_data_file_size is overwritten in next statement
so this assignment didn't ever get used.

Found by Coverity (ID 1409644)

CID 971836 (#1 of 1): Same on both sides (CONSTANT_EXPRESSION_RESULT)
pointless_expression: The expression val != end && val != end does not
accomplish anything because it evaluates to either of its identical
operands, val != end.

Problem was that in a circular replication setup the master remembers
position to events it has generated itself when reading from a slave.
If there are no new events in the queue from the slave, a
Gtid_list_log_event is generated to remember the last skipped event.
The problem happens if there is a network delay and we generate a
Gtid_list_log_event in the middle of the transaction, in which case there
will be an implicit comment and a new transaction with serverid=0 will be
logged.

The fix was to not generate any Gtid_list_log_events in the middle of a
transaction.

This could happen when the client connection dies while sending a progress
report packet.
Fixed by not raising any errors when sending progress packets.

tmp variable now points to str->ptr() buffer, not tmp_value buffer.
Comparing pointers otherwise can lead to false assertion errors as we
don't know where buffers are allocated in respect to each other.

cover ANSI_QUOTES and NO_BACKSLASH_ESCAPES in mysqltest

don't do backslash escapes inside backticks

MDEV-12975 InnoDB redo log minimum size check uses detected file size instead of requested innodb_log_file_size

log_calc_max_ages(): Use the requested size in the check, instead of
the detected redo log size. The redo log will be resized at startup
if it differs from what has been requested.

The bug happens because of a combination of unfortunate circumstances:

1. Arguments args[0] and args[2] of Item_func_concat point recursively
(through Item_direct_view_ref's) to the same Item_func_conv_charset.
Both args[0]->args[0]->ref[0] and args[2]->args[0]->ref[0] refer to
this Item_func_conv_charset.

2. When Item_func_concat::args[0]->val_str() is called,
Item_func_conv_charset::val_str() writes its result to
Item_func_conc_charset::tmp_value.

3. Then, for optimization purposes (to avoid copying),
Item_func_substr::val_str() initializes Item_func_substr::tmp_value
to point to the buffer fragment owned by Item_func_conv_charset::tmp_value
Item_func_substr::tmp_value is returned as a result of
Item_func_concat::args[0]->val_str().

4. Due to optimization to avoid memory reallocs,
Item_func_concat::val_str() remembers the result of args[0]->val_str()
in "res" and further uses "res" to collect the return value.

5. When Item_func_concat::args[2]->val_str() is called,
Item_func_conv_charset::tmp_value gets overwritten (see #1),
which effectively overwrites args[0]'s Item_func_substr::tmp_value (see #3),
which effectively overwrites "res" (see #4).

This patch does the following:

a. Changes Item_func_conv_charset::val_str(String *str) to use
   tmp_value and str the other way around. After this change tmp_value
   is used to store a temporary result, while str is used to return the value.
   The fixes the second problem (without SUBSTR):
     SELECT CONCAT(t2,'-',t2) c2
       FROM (SELECT CONVERT(t USING latin1) t2 FROM t1) sub;
   As Item_func_concat::val_str() supplies two different buffers when calling
   args[0]->val_str() and args[2]->val_str(), in the new reduction the result
   created during args[0]->val_str() does not get overwritten by
   args[2]->val_str().

b. Fixing the same problem in val_str() for similar classes

   Item_func_to_base64
   Item_func_from_base64
   Item_func_weight_string
   Item_func_hex
   Item_func_unhex
   Item_func_quote
   Item_func_compress
   Item_func_uncompress
   Item_func_des_encrypt
   Item_func_des_decrypt
   Item_func_conv_charset
   Item_func_reverse
   Item_func_soundex
   Item_func_aes_encrypt
   Item_func_aes_decrypt
   Item_func_buffer

c. Fixing Item_func::val_str_from_val_str_ascii() the same way.
   Now Item_str_ascii_func::ascii_buff is used for temporary value,
   while the parameter passed to val_str() is used to return the result.
   This fixes the same problem when conversion (from ASCII to e.g. UCS2)
   takes place. See the ctype_ucs.test for example queries that returned
   wrong results before the fix.

d. Some Item_func descendand classes had temporary String buffers
   (tmp_value and tmp_str), but did not really use them.
   Removing these temporary buffers from:

   Item_func_decode_histogram
   Item_func_format
   Item_func_binlog_gtid_pos
   Item_func_spatial_collection:

e. Removing Item_func_buffer::tmp_value, because it's not used any more.

f. Renaming Item_func_[un]compress::buffer to "tmp_value",
   for consistency with other classes.

Note, this patch does not fix the following classes
(although they have a similar problem):

   Item_str_conv
   Item_func_make_set
   Item_char_typecast

They have a complex implementations and simple swapping between "tmp_value"
and "str" won't work. These classes will be fixed separately.

This has been implemented in for cmake-3.6 to match distro version
of what the filename should look like.

Thanks to Domen Vranka for the suggestion.

regex didn't replace lines that were split by 16K chunk reads.

The problem lies in how CURRENT_ROLE is defined. The
Item_func_current_role inherits from Item_func_sysconst, which defines
a safe_charset_converter to be a const_charset_converter.

During view creation, if there is no role previously set, the current_role()
function returns NULL.

This is captured on item instantiation and the
const_charset_converter call subsequently returns an Item_null.
In turn, the function is replaced with Item_null and the view is
then created with an Item_null instead of Item_func_current_role.

Without this patch, the first SHOW CREATE VIEW from the testcase would
have a where clause of WHERE role_name = NULL, while the second SHOW
CREATE VIEW would show a correctly created view.

The same applies for the DATABASE function, as it can change as well.

There is an additional problem with CURRENT_ROLE() when used in a
prepared statement. During prepared statement creation we used to set
the string_value of the function to the current role as well as the
null_value flag. During execution, if CURRENT_ROLE was not null, the
null_value flag was never set to not-null during fix_fields.

Item_func_current_user however can never be NULL so it did not show this
problem in a view before. At the same time, the CURRENT_USER() can not
be changed between prepared statement execution and creation so the
implementation where the value is stored during fix_fields is
sufficient.

Note also that DATABASE() function behaves differently during prepared
statements. See bug 25843 for details or commit
7e0ad09e