a better fix

fix another similar line

followup for 7828ba0d

codership/mysql-wsrep#318 Adapt MTR tests to new Galera status variables
                          and fix exposed leaks

In certain cases it is possible that transaction has populated
keys in the provider but during commit time the IO cache is
empty, so the provider commit does not happen (for example
early ROLLBACK TO SAVEPOINT followed by COMMIT). Run
provider post_rollback() to clean up the transaction object.

in a specially crafted invalid packet, one can get end_pos < pos here

disable online alter add primary key for innodb, if the
table is opened/locked more than once in the current connection

(see assert in ha_innobase::add_index())

test case

Any expensive WHERE condition for a table-less query with
implicit aggregation was lost. As a result the used aggregate
functions were calculated over a non-empty set of rows even
in the case when the condition was false.

Also clarify which --{no-,}default* options, must be first.

Sample output:
$  client/mysql --help
client/mysql  Ver 15.1 Distrib 5.5.59-MariaDB, for Linux (x86_64) using readline 5.1
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Usage: client/mysql [OPTIONS] [database]

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf
The following groups are read: mysql client client-server client-mariadb
The following options may be given as the first argument:
--print-defaults          Print the program argument list and exit.
--no-defaults             Don't read default options from any option file.
The following specify which files/groups are read (specified before other options):
--defaults-file=#         Only read default options from the given file #.
--defaults-extra-file=#   Read this file after the global files are read.
--defaults-group-suffix=# Additionally read default groups with # appended as a suffix.

tests running from build directory:
TEST: print defaults ignored as not first
$ sql/mysqld  --no-defaults --print-defaults --lc-messages-dir=${PWD}/sql/share

TEST: no startup occurs as --print-defaults specified
$ sql/mysqld  --print-defaults --lc-messages-dir=${PWD}/sql/share
sql/mysqld would have been started with the following arguments:
--lc-messages-dir=/home/dan/repos/build-mariadb-5.5/sql/share

TEST: default args can't be anywhere
$ client/mysql --user=bob  --defaults-file=/etc/my.cnf
client/mysql: unknown variable 'defaults-file=/etc/my.cnf'
$ client/mysql --user=bob  --defaults-group-suffix=.group
client/mysql: unknown variable 'defaults-group-suffix=.group'

/etc/my.cnf:
[client-server.group]
socket=/var/lib/mysql-multi/group/mysqld.sock
user=bob

/etc/my.other.cnf:
socket=/var/lib/mysql-other/mysqld.sock

TEST: defaults file read and suffix also applied
$  client/mysql  --defaults-file=/etc/my.other.cnf  --defaults-group-suffix=.group
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql-other/mysqld.sock' (2)

TEST: defaults extra file
$ client/mysql  --defaults-extra-file=/etc/my.other.cnf  --defaults-group-suffix=.group
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql-other/mysqld.sock' (2)

condition fixed.

handler::ha_create_handler_files shouldn't call the
mark_trx_read_write() for the temporary table.

MDEV-15023 - wsrep_sst_mysqldump: safer test of version != 5

MDEV-15624 Changing the default character set to utf8mb4 changes query evaluation in a very surprising way

warning: format '%p' expects argument of type 'void *', but argument 4 has type 'long int'

For this case we have a view that is mergeable but we are not able to merge it in the
parent select because that would exceed the maximum tables allowed in the join list, so we
materialise this view
TABLE_LIST::dervied is NULL for such views, it is only set for views which have ALGORITHM=TEMPTABLE
Fixed by making sure TABLE_LIST::derived is set for views that could not be merged

A simple patch fixing the problem in 5.5.
Note, a full patch was previously fixed to 10.3.

Conversion of a subquery to a semi-join is blocked when we have an
IN subquery predicate in the on_expr of an outer join. Currently this
scenario is handled but the cases when an IN subquery predicate is wrapped
inside a Item_in_optimizer item then this blocking is not done.

Detection of first execution of PS fixed.
More debug info.

For the query having an IN subquery with no tables, we were converting the subquery with an expression between
the left part and the select list of the subquery . This can give incorrect results when we have a condition
in the subquery with a dual table (as this is treated as a no table).

The fix is that we don't do this conversion when we have conds in the subquery with a dual table.

mem_heap_create_block(): Poison the payload area until
mem_heap_alloc() unpoisons it.

Learn both valgrind and asan to catch this bug:

  mem_heap_t* heap = mem_heap_create(1024);
  byte* p = reinterpret_cast<byte*>(heap) + sizeof(mem_heap_t);
  *p = 123;

Overflows of the last allocation in a block will be catched too.

mem_heap_create_block(): poison newly allocated memory

As this is the only moderately critical fopened for writing file,
create an alternate path to use open and fdopen for non-glibc platforms
that support O_CLOEXEC (BSDs).

Tested on Linux (by modifing the GLIBC defination) to take this
alternate path:

$ cd /proc/23874
$ more fdinfo/71
pos:    0
flags:  02100001
mnt_id: 24
$ ls -la fd/71
l-wx------. 1 dan dan 64 Mar 14 13:30 fd/71 -> /dev/shm/var_auto_i7rl/mysqld.1/data/ib_buffer_pool.incomplete

Backport from 10.2

MDEV-8743: use CLOEXEC to protect mariadb files from sst script touching

MDEV-8743: ib_logfile0 Use O_CLOEXEC so galera SST scripts don't get fd

The issue is that we are creating a materialised table with key of length 0 which is incorrect, we should
disable materialisation for such a case.

Thread 1 "mysqld" hit Breakpoint 1, innobase_mysql_tmpfile () at /home/dan/repos/mariadb-server-5.5/storage/xtradb/handler/ha_innodb.cc:1639
1639            os_event_wait(srv_allow_writes_event);

(gdb) p fd
$2 = 7
(gdb) n
1682                    fd2 = fcntl(fd, F_DUPFD_CLOEXEC, 0);
(gdb)
1687                    if (fd2 < 0) {
(gdb) p fd2
$3 = 8

cat /proc/20448/fdinfo/{7,8}
  2051972      0 -r--------   1  dan      dan             0 Mar  2 12:04 fdinfo/7
pos:    0
flags:  0100002
mnt_id: 82
  2051973      0 -r--------   1  dan      dan             0 Mar  2 12:04 fdinfo/8
pos:    0
flags:  02100002
mnt_id: 82

So fd 8 has 02000000 hence CLOEXEC

From 0f447810