Fix memory barrier issues on releasing mutexes. We must have a full
memory barrier between releasing a mutex lock and reading its waiters.
This prevents us from missing to release waiters due to reading the
number of waiters speculatively before releasing the lock. If threads
try and wait between us reading the waiters count and releasing the
lock, those threads might stall indefinitely.

Also, we must use proper ACQUIRE/RELEASE semantics for atomic
operations, not ACQUIRE/ACQUIRE.

Windows!

a correct fix:
* store properly quoted table names in tables4repair/etc lists
* tell handle_request_for_tables whether the name is aalready properly quoted
* test cases for all uses of fix_table_name()

followup

tmp_join may get its tables freed twice during JOIN cleanup. Set them to NULL
when the tmp_join is different than the current join.

MDEV-10500 CASE/IF Statement returns multiple values and shifts further result values to the next column

We assume all around the code that null_value==true is in sync
with NULL value returned by val_str()/val_decimal().
Item_sum_sum::val_decimal() erroneously returned a non-NULL value together
with null_value set to true. Fixing to return NULL instead.

thd->clear_error() destroyed already existing error status

Make the testcase stable by adding FORCE INDEX

Shared variables of Delayed_insert may be updated without mutex protection
when delayed insert thread gets an error.

Re-acquire mutex earlier, so that shared variables are protected.

This issue was discovered by
Dawid Golunski (http://legalhackers.com)

removed

wait until the failed connection thread completely dies
before uninstalling pam plugin

don't mark transactions read-write if no real storage engine is affected (only binlog writes).

without a fix for Bug#12818255 (MDEV-6581)

SRWLock acquisition

Backport patch from 10.1

Make sure current fiber is saved in my_context::app_fiber
in both my_context_spawn() and my_context_continue()

Backporting MDEV-5781 from 10.0.

MDEV-10217: innodb.innodb_bug59641 fails sporadically in buildbot: InnoDB: Failing assertion: current_rec != insert_rec in file page0cur.c line 1052

Added record printout when current_rec == insert_rec with lengths for
debug builds.

Use FILE_FLAG_FIRST_PIPE_INSTANCE with the first CreateNamedPipe()
call to make sure the pipe does not already exist.

Fixed initialization and usage of THD reference in subselect engines.

Fix get_quick_keys(): When building range tree from a condition
in form

  keypart1=const AND (keypart2 < 0 OR keypart2>=0)

the SEL_ARG for keypart2 represents an interval (-inf, +inf).
However, the logic that sets UNIQUE_RANGE flag fails to recognize
this, and sets UNIQUE_RANGE flag if (keypart1, keypart2) covered
a unique key.
As a result, range access executor assumes the interval can have
at most one row and only reads the first row from it.

A better fix for MySQL Bug#41776: use hard timestamp rather than unreliable
sleep.

While dropping the test database, use IF EXISTS to avoid bogus errors

add a test case

MDEV-10318 : Fix crash in embedded, in case prepared statement has parameter placeholders, but does not bind parameters

Remove mysql_config from client sub-package

(cherry picked from commit 45c4bfa0f3f1c70756591f48710bb3e76ffde9bc)

-LONGLONG_MIN is the undefined behavior in C.
longlong2decimal() used to do this:

  int longlong2decimal(longlong from, decimal_t *to) {
    if ((to->sign= from < 0))
      return ull2dec(-from, to);
    return ull2dec(from, to);

and later in ull2dec() (DIG_BASE is 1000000000):

  static int ull2dec(ulonglong from, decimal_t *to) {
    for (intg1=1; from >= DIG_BASE; intg1++, from/=DIG_BASE) {}

this breaks in gcc-5 at -O3. Here ull2dec is inlined into
longlong2decimal. And gcc-5 believes that 'from' in the
inlined ull2dec is always a positive integer (indeed, if it was
negative, then -from was used instead). So gcc-5 uses
*signed* comparison with DIG_BASE.

Fix: make a special case for LONGLONG_MIN, don't negate it

State column of SHOW PROCESSLIST can have NULL values for being initialized
threads (between new connection was acknowledged and waiting for network data).

Fixed test case to handle such cases by waiting for State to become empty
string.

thd should not be taken earlier then fix_field and reset on fix_fields if it is needed.

Analysis: row_drop_table_for_mysql did not allow dropping
referenced table even in case when actual creating of the
referenced table was not successfull if foreign_key_checks=1.

Fix: Allow dropping referenced table even if foreign_key_checks=1
if actual table create returned error.

quote identifiers correctly

and
MDEV-10250 InnoDB: Error: File (unknown): 'close' returned OS error 209. Cannot continue operation"

after a failed connect() feedback plugin was continuing with the
file descriptor, trying to send the data (which failed) and
closing it at the end. Even though this fd might've been reused for
something else already.

             shutdown)

There was race condition between shutdown thread and event worker threads.

Shutdown thread waits for thread_count to become 0 in close_connections(). It
may happen so that event worker thread was started but didn't increment
thread_count by this time. In this case shutdown thread may miss wait for this
working thread and continue deinitialization. Worker thread in turn may continue
execution and crash on deinitialized data.

Fixed by incrementing thread_count before thread is actually created like it is
done for connection threads.

Also let event scheduler not to inc/dec running threads counter for symmetry
with other "service" threads.