Almost trivial rw_lock_t::waiters transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform atomic initialisation.
Almost trivial rw_lock_t::lock_word transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform atomic initialisation.
Also made previously broken code in gis0sea.cc even more broken. It is
unclear how it was supposed to work and what exactly it was supposed to
do.
Trivial buf_tmp_buffer_t::reserved transition.
Relaxed memory order looks suspicious when used by methods that have
acquire()/release() names. Especially if intention is to transfer some
variable or memory region from one thread to another. Or is memory
ordering guaranteed by something else, e.g. some mutex that protects
broader range of acquire/release functionality?
Almost trivial TTASEventMutex::m_lock_word transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform all accesses atomically.
Almost trivial TTASMutex::m_lock_word transition. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform all accesses atomically.
rw_trx_hash_element_t::no transition to Atomic_counter. Since C++11
doesn't seem to allow mixed (atomic and non-atomic) access to atomic
variables, we have to perform atomic initialisation.
Almost trivial trx_sys_t::m_rw_trx_hash_version transition. Since C++11
doesn't seem to allow mixed (atomic and non-atomic) access to atomic
variables, we have to perform atomic initialisation.
trx_sys_t::m_max_trx_id transition to Atomic_counter. Since C++11 doesn't
seem to allow mixed (atomic and non-atomic) access to atomic variables,
we have to perform atomic initialisation.
The fix for MDEV-17901 did not cover cases where the AUTO_INCREMENT
column was not dropped, but some other columns before it were.
commit_cache_norebuild(): Revert the MDEV-17901 fix.
dict_index_t::clear_instant_alter(): Update table->persistent_autoinc.
innobase_instant_try(): Only try to update the hidden metadata
record if the number of columns is changing (increasing) or
a metadata BLOB is being added due to permuting or dropping columns
for the first time.
dict_table_t::instant_column(), ha_innobase_inplace_ctx::instant_column():
Return whether the metadata record needs to be updated.
Ubuntu 14.04 Trusty is LTS until April 2019 and since we are
approaching that, upgrade to Xenial which is LTS until April 2021.
One bonus of this upgrade is that the Travis Xenial virtual images
have a much bigger disk size, thus no need to limit ccache below
the default of 5G anymore.
Also had to remove linux/clang-8 toolchain testing since
llvm-toolchain-xenial is not listed at:
https://github.com/travis-ci/apt-source-safelist/blob/master/ubuntu.json
And fails with:
Disallowing sources: llvm-toolchain-xenial
...
E: Unable to locate package clang-8
E: Unable to locate package llvm-8-dev
This assertion should have been relaxed when implementing the first part of
MDEV-15563: instant removal of NOT NULL attribute for ROW_FORMAT=REDUNDANT
tables.
For ROW_FORMAT=REDUNDANT, there is no bitmap of null columns;
the null flags are encoded in the end offset of each field.
We do not really care about the number of fields that can be NULL.
Ensure that the 'auxiliary transactions' that are there for
flushing the incomplete undo log of the to-be-recovered DDL
transactions are actually making modifications.
Starting with commit 6b6987154a
the encrypted page checksum is only computed with crc32.
Encrypted data pages that were written earlier can contain
other checksums, but new ones will only contain crc32.
Because of this, it does not make sense to implement strict
checks of innodb_checksum_algorithm for other than strict_crc32.
fil_space_verify_crypt_checksum(): Treat strict_innodb as innodb
and strict_none as none. That is, allow a match from any of the
algorithms none, innodb, crc32. (This is how it worked before the
second MDEV-12112 fix.)
Thanks to Thirunarayanan Balathandayuthapani for pointing this out.
The initial fix only covered a part of Mariabackup.
This fix hardens InnoDB and XtraDB in a similar way, in order
to reduce the probability of mistaking a corrupted encrypted page
for a valid unencrypted one.
This is based on work by Thirunarayanan Balathandayuthapani.
fil_space_verify_crypt_checksum(): Assert that key_version!=0.
Let the callers guarantee that. Now that we have this assertion,
we also know that buf_page_is_zeroes() cannot hold.
Also, remove all diagnostic output and related parameters,
and let the relevant callers emit such messages.
Last but not least, validate the post-encryption checksum
according to the innodb_checksum_algorithm (only accepting
one checksum for the strict variants), and no longer
try to validate the page as if it was unencrypted.
buf_page_is_zeroes(): Move to the compilation unit of the only callers,
and declare static.
xb_fil_cur_read(), buf_page_check_corrupt(): Add a condition before
calling fil_space_verify_crypt_checksum(). This is a non-functional
change.
buf_dblwr_process(): Validate the page only as encrypted or unencrypted,
but not both.
