The code in OIN::optimize_inner() has this call

   calc_group_buffer(this, group_list)

the call is however bypassed when the optimizer figures out that the JOIN
has "Impossible WHERE".

If we attempt to calculate the value of a window function afterwards,
we will get a crash when trying to create a temporary table.

So, put a call to calc_group_buffer() here as well. It's a bit surprising
that all these steps are done for a query that will produce zero rows
but we are just following the approach taken by the fix for mdev-11999
here.

Make st_select_lex::set_explain_type() take into account that JOIN_TABs
it is traversing may be also post-join aggregation JOIN_TABs (which
have pos_in_table_list=NULL, etc).

Add a testcase

Do not run the window function computation step when the select
produces no rows (zero_result_cause!=NULL).
This may cause reads from uninitialized memory.

We still need to run the window function computation step when
the output includes just one row  (for example
SELECT MAX(col), RANK() OVER (...) FROM t1 WHERE 1=0).

This fix also resolves an issue with queries with window functions
producing an output row where should be none, like in
SELECT ROW_NUMBER() FROM t1 WHERE 1=0.

Updated a few test results in the existing tests to reflect this.

during build on 10.2 following files are generated:

  * scripts/galera_new_cluster
  * scripts/galera_recovery
  * support-files/mariadb.service
  * support-files/mariadb.pp

and they are untracked for git. Let's add them to .gitignore

Fixed null pointer dereference in parsing "show full processlist" output
with atoi().

Some  Innodb background thread has NULL in 'Time' column,
thus  backup would crash with when atoi is applied to null pointer.

this failed json.test on fulltest2 builder

because they compile with -Werror=format-security

.files extension is not used by debian packaging, .install is.

Whenever Filesort_tracker has r_loops=0, r_ouptut_rows would be 0, so we should add the value zero
to the member "r_output_rows" explicitly

Adjust results for storage_engine tests

Adjust results for tests in non-default suites

Adjust search paths for mariadb_config and make further assignment
conditional

MDEV-13267 At startup with crash recovery: mtr_t::commit_checkpoint(lsn_t, bool): Assertion `!recv_no_log_write' failed

This is a bogus debug assertion failure that should be possible
starting with MariaDB 10.2.2 (which merged WL#7142 via MySQL 5.7.9).

While generating page-change redo log records is strictly out of the
question during tat certain parts of crash recovery, the
fil_names_clear() is only emitting informational MLOG_FILE_NAME
and MLOG_CHECKPOINT records to guarantee that if the server is killed
during or soon after the crash recovery, subsequent crash recovery
will be possible.

The metadata buffer that fil_names_clear() is flushing to the redo log
is being filled by recv_init_crash_recovery_spaces(), right before
starting to apply redo log, by invoking fil_names_dirty() on every
discovered tablespace for which there are changes to apply.

When it comes to Mariabackup (xtrabackup --prepare), it is strictly out
of the question to generate any redo log whatsoever, because that could
break the restore of incremental backups by causing LSN deviation.
So, the fil_names_dirty() call must be skipped when restoring backups.

recv_recovery_from_checkpoint_start(): Do not invoke fil_names_clear()
when restoring a backup.

mtr_t::commit_checkpoint(): Remove the failing assertion. The only
caller is fil_names_clear(), and it must be called by
recv_recovery_from_checkpoint_start() for normal server startup to be
crash-safe. The debug assertion in mtr_t::commit() will still
catch rogue redo log writes.

Even disabling the ccache on the Debian build didn't always prevent
the Travis build running out of space.

As an alternative strategy, the number of alternative compilers has been
reduced to save space. This additional space has been partially reused
by the ccache.

Debian build specific packages have been removed from other builds.

(10.0+ changes, as specified in the MDEV)

and remove unused variable (compiler warning)

There is an inherent race condition between Mariabackup and the
MariaDB server when the InnoDB redo log is being copied. It is
possible that the tail of the circular redo log is overwriting
the head of the log before Mariabackup gets a chance to read it.
So, we reduce the test to generate less redo log. Also, enable
the test on all supported innodb_page_size.

xtrabackup_copy_log(), xtrabackup_copy_logfile():
Change the Boolean parameter to an enum, with the values
COPY_FIRST, COPY_ONLINE, COPY_LAST.

xtrabackup_copy_log(): Return the latest scanned LSN,
which may be less than the last copied LSN. Remove some
dead code that was duplicating some logic that in 10.2
has been moved to log_group_read_log_seg().

log_copying_thread(): Correct the termination condition.

stop_backup_threads(): Shut down the threads that were
created during backup.

Use GET_STR instead of GET_STR_ALLOC, so that the memory will
cannot be leaked. For some reason, calling my_cleanup_options()
on xb_server_options or xb_client_options would not work.

This reduces the probability having output of external utilities
(e.g mariabackup) truncated.

MDEV-12445 : Rocksdb does not shutdown worker threads and aborts in memleak check on server shutdown

Disable memory leak check in debug server, if rocksdb is loaded.
There is some subtle bug somewhere in 3rd party code we cannot
do much about.

The bug is manifested as follows

Rocksdb does not shutdown worker threads, when plugin is shut down. Thus
OS does not unload the library since there are some active threads using
this library's code. Thus global destructors in the library do not run,
and there is still some memory allocated when server exits.

The workaround disables server's memory leak check, if rocksdb engine was
loaded.

Use thd_query_safe() to read query from a different connection.

The option innodb_log_compressed_pages was contributed by
Facebook to MySQL 5.6. It was disabled in the 5.6.10 GA release
due to problems that were fixed in 5.6.11, which is when the
option was enabled.

The option was set to innodb_log_compressed_pages=ON by default
(disabling the feature), because safety was considered more
important than speed. The option innodb_log_compressed_pages=OFF
can *CORRUPT* ROW_FORMAT=COMPRESSED tables on crash recovery
if the zlib deflate function is behaving differently (producing
a different amount of compressed data) from how it behaved
when the redo log records were written (prior to the crash recovery).

In MDEV-6935, the default value was changed to
innodb_log_compressed_pages=OFF. This is inherently unsafe, because
there are very many different environments where MariaDB can be
running, using different zlib versions. While zlib can decompress
data just fine, there are no guarantees that different versions will
always compress the same data to the exactly same size. To avoid
problems related to zlib upgrades or version mismatch, we must
use a safe default setting.

This will reduce the write performance for users of
ROW_FORMAT=COMPRESSED tables. If you configure
innodb_log_compressed_pages=ON, please make sure that you will
always cleanly shut down InnoDB before upgrading the server
or zlib.