MDEV-22596: DELETE FOR PORTION does not obey "Expression in FOR PORTION OF must be constant" limitation, data can be easily lost
DELETE...FOR PORTION OF... statement accepts non-constant
FROM...TO clause. This contradicts the documentation and
is inconsistent with the behavior of UPDATE statement.
Thus, we add a validation that checks if a given deletion
period is specified by constant.
Travis-CI: Use new Ubuntu 20.04 as base, streamline and document
Simplify Travis-CI file and extend inline comments.
Upgrade to using Ubuntu 20.04 (Focal) as the baseline distro version
now that Travis-CI has made it available. Drop Xenial and all the
excess repositories Xenial needed. Now we only Focal and one Bionic
build to keep things simple and streamlined.
Keep GCC-7/Clang-7 as the older compiler, and start using GCC-10
and Clang-10 as the newer compiler. Assume that if both of them
build OK, than the intermediate versions would be OK as well.
Print 'apt-cache policy' to make it transparent in build logs what
repositories was used for build dependencies.
Remove temporary workaround from homebrew install step as Travis-CI has
fixed the original issue.
Revert ignoring results form build that previously failed on the test
main.thread_pool_info as MDEV-20372 is not fixed.
Keep arm64 failures ignored due to MDEV-23955.
Allow failures for the test main.column_compression 'innodb' due
to MDEV-23954 (already fixed, but not on 10.6 branch yet).
The setting innodb_lock_schedule_algorithm=VATS that was introduced
in MDEV-11039 (commit 021212b525e39d332cddd0b9f1656e2fa8044905)
causes conflicting exclusive locks to be incorrectly granted to
two transactions. Specifically, in lock_rec_insert_by_trx_age()
the predicate !lock_rec_has_to_wait_in_queue(in_lock) would hold even
though an active transaction is already holding an exclusive lock.
This was observed between two DELETE of the same clustered index record.
The HASH_DELETE invocation in lock_rec_enqueue_waiting() may be related.
Due to lack of progress in diagnosing the problem, we will remove the
option. The unsafe option was enabled by default between
commit 0c15d1a6ff0d18da946f050cfeac176387a76112 (MariaDB 10.2.3)
and the parent of
commit 1cc1d0429da14a041a6240c6fce17e0d31cad8e2 (MariaDB 10.2.17, 10.3.9),
and it was deprecated in
commit 295e2d500b31819422c97ad77beb6226b961c207 (MariaDB 10.2.34).
In merge commit 34212233634b53a4fea7f662c43c19028aec2c2a
buf_page_create() passed the wrong parameter to
one of the buf_LRU_block_free_non_file_page() calls.
When commit 0fd3def284b78dff71590686e8f82571fc3808e1 removed
the MLOG_UNDO_ERASE_END record in MariaDB 10.3.3 in an attempt
to reduce our redo log volume, it introduced technical debt for
commit 56f6dab1d0e5a464ea49c1e5efb0032a0f5cea3e (MDEV-21174) and
commit 7ae21b18a6b73bbc3bf1ff448faf60c29ac1d386 (MDEV-12353),
which optimized mtr_t::write() (née mlog_write_ulint()) so
that the initial bytes that are unchanged are not logged.
trx_undo_report_row_operation(): Write a log record for the
memset() operation if the page is not going to be freed.
