Apply the correct pattern for debug instrumentation:

SET @save_dbug=@@debug_dbug;
SET debug_dbug='+d,...';
...
SET debug_dbug=@save_dbug;

Numerous tests use statements of the form

SET debug_dbug='-d,...';

which will inadvertently enable all DBUG tracing output,
causing unnecessary waste of resources.

The function was declared but not defined in
commit 9d6d1902

MDEV-20495 Assertion `precision > 0' failed in decimal_bin_size upon CREATE .. SELECT with zerofilled decimal

Also fixes:

MDEV-20560 Assertion `precision > 0' failed in decimal_bin_size upon SELECT with MOD short unsigned decimal

Changing the way how Item_func_mod calculates its max_length.
It now uses decimal_precision(), decimal_scale() and unsigned_flag
of its arguments, like all other Item_num_op descendants do.

"--defaults-group-suffix" must be be given as the first argument on the command-line of mysqld

* Change the comments in mysql-log-rotate.sh to refer to mysqld, not mysqld_safe
  as that's what most distros are using.
* Change err-log to log-error as err-log is no longer valid.
* Convert tab to space for consistency.

Fix build error with newer cmake

Fixes the following build error:

CMake Error at cmake/os/Linux.cmake:29 (STRING):
STRING sub-command REPLACE requires at least four arguments.
Call Stack (most recent call first):
CMakeLists.txt:101 (INCLUDE)

CMake Error at cmake/os/Linux.cmake:29 (STRING):
STRING sub-command REPLACE requires at least four arguments.
Call Stack (most recent call first):
CMakeLists.txt:101 (INCLUDE)

The error happens when CMAKE_SHARED_LINKER_{LANG}_FLAGS is not set.
Force the variable to be set to "" as input to prevent this.
Signed-off-by: Ryan Coe <bluemrp9@gmail.com>
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>

don't run tokudb tests under tcmalloc,
this is not a supported combination.

This patch corrects the fix of the patch for mdev-19421 that resolved
the problem of parsing some embedded join expressions such as
  t1 join t2 left join t3 on t2.a=t3.a on t1.a=t2.a.
Yet the patch contained a bug that prevented proper context analysis
of the queries where such expressions were used together with comma
separated table references in from clauses.

MDEV-15955 Assertion `field_types == 0 || field_types[field_pos] == MYSQL_TYPE_LONGLONG' failed in Protocol_text::store_longlong

Analysis
========
Point in time recovery using mysqlbinlog containing queries
operating on temporary tables results in an error.

While writing the query log event in the binary log, the
thread id used for execution of DROP TABLE and DELETE commands
were incorrect. The thread variable 'thread_specific_used'
is used to determine whether a specific thread id is to used
while executing the statements i.e using 'SET
@@session.pseudo_thread_id'. This variable was not set
correctly for DROP TABLE query and was never set for DELETE
query. The thread id is important for temporary tables
since the tables are session specific. DROP TABLE and DELETE
queries executed using a wrong thread id resulted in errors
while applying the queries generated by mysqlbinlog utility.

Fix
===
Set the 'thread_specific_used' THD variable for DROP TABLE and
DELETE queries.

ReviewBoard: 21833

Note: this patch is for 5.6.

Detected by ASAN.

The patch fixes the cleanup of parser stack pointers.
Reviewed-by: Guilhem Bichot <guilhem.bichot@oracle.com>

check_valid_path() uses my_strcspn() that cannot handle invalid characters
properly. This is fixed by a big refactoring in 10.2 (MDEV-6353).

For 5.5, let's simply swap tests, because check_string_char_length()
rejects invalid characters just fine.

Description:- During server startup, the server exits if
the 'mysql.plugin' system table has any rows with empty
value for the field 'name' (plugin name).

The xpath parsing function was using a local string buffer that was
deallocated when going out of scope. However references to it are
preserved in the XPATH parse tree. This was causing read-after-free.

Fixed by making the xpath buffer a local variable inside the Item
class for the relevant xpath function, thus being preserved for the
duration of the query.

DESCRIPTION
===========
PVS-Studio static code analyzer found several suspicious
fragments of code across various files.

i)   sizeof() is using the pointer
ii)  memcpy() doesn't copy the whole string.
iii) enumeration constant 'wkb_multilinestring' is used as
     a variable of a Boolean-type.
iv) 'throw' keyword is missing from std::runtime_error()

FIX
===
i)   Use sizeof({actual object/data type})
ii)  Use strncpy() and set last char as '\0'
iii) N/A (Issue has already been fixed)
iv)  Add 'throw' before the exception.

RB: 21502

Follow-up to 07ba5560:
Use the correct 64-bit type name ulonglong instead of ulint,
like in mysql/mysql-server@4e0100d86b1b46be0107ebd46a98a0c2dbb0fab4

Problem: Clients running different values for auto_increment_increment
and doing concurrent inserts leads to "Duplicate key error" in one of them.

Analysis:
When auto_increment_increment value is reduced in a session,
InnoDB uses last auto_increment_increment value
to recalculate the autoinc value.
In case, some other session has inserted a value
with different auto_increment_increment, InnoDB recalculate
autoinc values based on current session previous auto_increment_increment
instead of considering the auto_increment_increment used for last insert
across all session

Fix:
revert 7acdf29c
a.k.a. 7c12a9e5
as it causing the bug.

Reviewed By:
Bin <bin.x.su@oracle.com>
Kevin <kevin.lewis@oracle.com>
RB#21777

Note: In MariaDB Server, earlier changes in
ae5bc059
for MDEV-533 require that the original test in
mysql/mysql-server@1ccd472d63a042d3237a55f5827239164219ef7e
be adjusted for MariaDB.

Also, ef47b625 (MDEV-8827)
had to be reverted after the upstream fix had been backported.

This reverts commit ef47b625.
The parent commit 07ba5560
which is a backport of
mysql/mysql-server@1198267c331b045b9cad26be72b1a5b4f8930a79
fixes the issue differently.

Problem:
=======
Autoincrement value gives duplicate values because of the following reasons.

(1) In InnoDB handler function, current autoincrement value is not changed
based on newly set auto_increment_increment or auto_increment_offset variable.

(2) Handler function does the rounding logic and changes the current
autoincrement value and InnoDB doesn't aware of the change in current
autoincrement value.

Solution:
========
Fix the problem(1), InnoDB always respect the auto_increment_increment
and auto_increment_offset value in case of current autoincrement value.
By fixing the problem (2), handler layer won't change any current
autoincrement value.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 13748

reported by lixtelnis

Check EXISTS LIMIT before rewriting.

Check that table is really opened before cleanup using handler.

Use for parameters value conversion functions which issue warnings.

The parser returned a syntax error message for the queries with join
expressions like this t1 JOIN t2 [LEFT | RIGHT] JOIN t3 ON ... ON ... when
the second operand of the outer JOIN operation with ON clause was another
join expression with ON clause. In this expression the JOIN operator is
right-associative, i.e. expression has to be parsed as the expression
t1 JOIN (t2 [LEFT | RIGHT] JOIN t3 ON ... ) ON ...
Such join expressions are hard to parse because the outer JOIN is
left-associative if there is no ON clause for the first outer JOIN operator.
The patch implements the solution when the JOIN operator is always parsed
as right-associative and builds first the right-associative tree. If it
happens that there is no corresponding ON clause for this operator the
tree is converted to left-associative.

The idea of the solution was taken from the patch by Martin Hansson
"WL#8083: Fixed the join_table rule" from MySQL-8.0 code line.
As the grammar rules related to join expressions in MySQL-8.0 and
MariaDB-5.5+ are quite different MariaDB solution could not borrow
any code from the MySQL-8.0 solution.

pgrep will not be able to get th pid using the full path which is $libexec/mysqld unless -f is being used

Upgrade HeidiSQL to 10.2

Explain why it makes sense to not consider builddir == srcdir directly,
for cases when we do out-of-source builds.

The assumption in the original commit for --builddir (648d3ced),
was to assume that without a --builddir, and when --srcdir
is specified, that the builddir is the same as the srcdir.

The problem is that this assumption does not hold for out-of-source
builds and we can figure out the builddir by looking for where
mysql_install_db script is.

As mysql_install_db is in the builddir, we use dirname0 as the builddir after
checking that my_print_defaults is also located from dirname0, otherwise
default to old behavior.

           and WHERE filter afterwards

This patch complements the patch fixing the bug MDEV-6892. The latter
properly handled queries that used mergeable views returning constant
columns as inner tables of outer joins and whose where clause contained
predicates referring to these columns if the predicates of happened not
to be equality predicates. Otherwise the server still could return wrong
result sets for such queries. Besides the fix for MDEV-6892 prevented
some possible conversions of outer joins to inner joins for such queries.

This patch corrected the function check_simple_equality() to handle
properly conjunctive equalities of the where clause that refer to the
constant columns of mergeable views used as inner tables of an outer join.
The patch also changed the code of Item_direct_view_ref::not_null_tables().
This change allowed to take into account predicates containing references
to constant columns of mergeable views when converting outer joins into
inner joins.

Colors possibility auto detected. [ such ] stuff is colored.

Patch by Sergei Golubchik

           in where clause

The classes Item_func_isnottrue and Item_func_isnotfalse inherited the
implementation of the eval_not_null_tables method from the Item_func
class. As a result the not_null_tables_cache was set incorrectly for
the objects of these classes. It led to improper conversion of outer
joins to inner joins when the where clause of the processed query
contained IS NOT TRUE or IS NOT FALSE predicates. The coverted query
in many cases produced a wrong result set.