Clean-up periodic mutex/rwlock waiters wake up. This was a hack needed to
workaround broken mutexes/rwlocks implementation. We must have sane
implementations now and don't need these anymore: release thread is
guaranteed to wake up waiters.
Removed redundant ifdef that has equivalent code in both branches.
Removed os0atomic.h and os0atomic.ic: not used anymore.
Clean-up unused cmake checks.
Replaced InnoDB atomic operations with server atomic operations.
Moved INNODB_RW_LOCKS_USE_ATOMICS - it is always defined (code won't compile
otherwise).
NOTE: InnoDB uses thread identifiers as a target for atomic operations.
Thread identifiers should be considered opaque: any attempt to use a
thread ID other than in pthreads calls is nonportable and can lead to
unspecified results.
Contains also:
MDEV-10549 mysqld: sql/handler.cc:2692: int handler::ha_index_first(uchar*): Assertion `table_share->tmp_table != NO_TMP_TABLE || m_lock_type != 2' failed. (branch bb-10.2-jan)
Unlike MySQL, InnoDB still uses THR_LOCK in MariaDB
MDEV-10548 Some of the debug sync waits do not work with InnoDB 5.7 (branch bb-10.2-jan)
enable tests that were fixed in MDEV-10549
MDEV-10548 Some of the debug sync waits do not work with InnoDB 5.7 (branch bb-10.2-jan)
fix main.innodb_mysql_sync - re-enable online alter for partitioned innodb tables
Contains also
MDEV-10547: Test multi_update_innodb fails with InnoDB 5.7
The failure happened because 5.7 has changed the signature of
the bool handler::primary_key_is_clustered() const
virtual function ("const" was added). InnoDB was using the old
signature which caused the function not to be used.
MDEV-10550: Parallel replication lock waits/deadlock handling does not work with InnoDB 5.7
Fixed mutexing problem on lock_trx_handle_wait. Note that
rpl_parallel and rpl_optimistic_parallel tests still
fail.
MDEV-10156 : Group commit tests fail on 10.2 InnoDB (branch bb-10.2-jan)
Reason: incorrect merge
MDEV-10550: Parallel replication can't sync with master in InnoDB 5.7 (branch bb-10.2-jan)
Reason: incorrect merge
Bug #79636: CACHE_LINE_SIZE should be 128 on AArch64
Bug #79637: Hard-coded cache line size
Bug #79638: Reconcile CACHE_LINE_SIZE with CPU_LEVEL1_DCACHE_LINESIZE
Bug #79652: Suspicious padding in srv_conc_t
- changed CPU_LEVEL1_DCACHE_LINESIZE to default to 128 bytes on POWER
and AArch64 architectures in cases when no value could be detected
by CMake using getconf
- changed CACHE_LINE_SIZE definition in ut0counter.h to be an alias of
CPU_LEVEL1_DCACHE_LINESIZE
- changed a number of hard-coded 64-byte cache line size values in the
InnoDB code
- fixed insufficient padding for srv_conc members in srv0conc.cc
Ported to Mariadb by Daniel Black <daniel.black@au.ibm.com>
Added s390 cache size of 256 at same time.
Merged lp:maria/maria-10.0-galera up to revision 3879.
Added a new functions to handler API to forcefully abort_transaction,
producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These
were added for future possiblity to add more storage engines that
could use galera replication.
