(Could we just put the mark into bulk_load.inc ?)

Comment out a part of testcase that uses it.

This fixes result mismatches in rocksdb.issue111, rocksdb.hermitage,
rocksdb.rocksdb_locks

It compiles on Linux but fails a lot of tests still

commit 394d0712d3d46a87a8063e14e998e9c22336e3a6
Author: Anca Agape <anca@fb.com>
Date:   Thu Jul 27 15:43:07 2017 -0700

    Fix rpl.rpl_4threads_deadlock test broken by D5005670

    Summary:
    In D5005670 in fill_fields_processlist() function we introduced a point
    where we were trying to take the LOCK_thd_data before the
    synchronization point used by test
    processlist_after_LOCK_thd_count_before_LOCK_thd_data. This was
    happening in get_attached_srv_session() function called. Replaced this
    with get_attached_srv_session_safe() and moved it after lock is aquired.

    Reviewed By: tianx

    Differential Revision: D5505992

    fbshipit-source-id: bc53924

ha_partition creates temporary ha_XXX objects for its partitions when
performing DDL operations. The objects were created on a MEM_ROOT and
never deleted.
This works as long as ha_XXX objects free all data ha_XXX::close() and
don't rely on a proper destructor invocation. Unfortunately, ha_rocksdb
includes String members which need to be delete'd properly.

Fixed the bug by having ha_partition::~ha_partition delete these temporary
objects.

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.