80% reverted

Correct context chain made to allow outer fields pullout.

Post push fix: Solaris 10 /bin/sh don't understand $().

[This is the 5.5/5.6 version of the bugfix].

The problem was that it was possible to write log files ending
in .ini/.cnf that later could be parsed as an options file.
This made it possible for users to specify startup options
without the permissions to do so.

This patch fixes the problem by disallowing general query log
and slow query log to be written to files ending in .ini and .cnf.

During REPAIR TABLE of a MyISAM table, a temporary data file (.TMD)
is created. When repair finishes, this file is renamed to the original
.MYD file. The problem was that during this rename, we copied the
stats from the old file to the new file with chmod/chown. If a user
managed to replace the temporary file before chmod/chown was executed,
it was possible to get an arbitrary file with the privileges of the
mysql user.

This patch fixes the problem by not copying stats from the old
file to the new file. This is not needed as the new file was
created with the correct stats. This fix only changes server
behavior - external utilities such as myisamchk still does
chmod/chown.

No test case provided since the problem involves synchronization
with file system operations.

Argument to malloc-lib must be included in restricted list of
directories, symlink guards added, and mysqld and mysqld-version
options restricted to command line only. Don't redirect errors to
stderr.

The issue was that in some extreme cases when doing GROUP BY,
buffers for temporary blobs where not properly cleared.

Windows packaging : use /d switch to sign MSI, to prevent installer showing randomly generated name in UAC prompt

Reexecution of prepared "ANALYZE TABLE merge_table, table" may miss to
reinitialize "table" for subsequent execution and trigger assertion failure.

This happens because MERGE engine may adjust table->next_global chain, which
gets cleared by close_thread_tables()/ha_myisammrg::detach_children() later.
Since reinitilization iterates next_global chain, it won't see tables following
merge table.

Fixed by appending saved next_global chain after merge children.

"C:\Program Files (x86)" directory needs to be checked as well in
this case.

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

It happens when you are trying to read two or more log files from a
remote server using mysqlbinlog utility.

The reason for this is no matching mysql_close() that concludes the
life time of 'mysql' struct describing connection to the server.
This happens when mysqlbinlog is invoked with connecting to the server
and requesting more than one binlog file. In such case
dump_remote_log_entries() keeps calling safe_connect() per eachfile,
never caring to invoke mysql_close(). Only the final safe_connect()'s
allocation effect are cleaned by the base code.
That is with 2 files there's one 'mysql' connection descriptor struct
uncleaned/deallocated.

We are backporting the bug 21255763 (pushed in mysql-trunk)
in the earlier version of MySQL starting from 5.5 to 5.7.
which was pushed in mysql-trunk.

Fix:
Invoke mysql_close() just before mysql_init() in safe_connect()
defined in mysqlbinlog.cc. That makes possibly previously used 'mysql' be
reclaimed prior a new one is allocated.

Make the testcase stable by adding FORCE INDEX

Reverting the patch due to some issues.

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.

ISSUE: Queries with mediumint as column when operated with
long long type of data results in buffer overflow in
store_long function.

The merging rule specified for (MYSQL_TYPE_LONGLONG
MYSQL_TYPE_INT24) is MYSQL_TYPE_LONG. Due to this store_long
function was getting called which resulted in buffer overflow.

SOLUTION:
The correct merging rule for (MYSQL_TYPE_LONGLONG,
MYSQL_TYPE_INT24) should be MYSQL_TYPE_LONGLONG.
So, instead of function store_long, function store_longlong
is called which correctly handles the type MYSQL_TYPE_LONGLONG.

External Bug #23645238 is a duplicate of this issue.

               DERIVED TABLE IN JOIN

ISSUE:
------
This problem occurs under the following conditions:
1) A parameter is used in the select-list of a derived table.
2) The derived table is part of a JOIN.

SOLUTION:
---------
When a derived table is materialized, a temporary table is
created. This temporary table creates a field each for the
items in the select-list of the derived table. This set of
fields is later used to setup the join.

Currently no field is created in the temporary table if a
parameter is used in the select-list.

Create a field for the parameter. By default Item_param's
result type in a prepared statement is set to
STRING_RESULT. This can change during the execute phase
depending on the user variable. But since the execute phase
creates its own temporary table, it will be handled
separately.

This is a backport of the fix for BUG#22392374.

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