| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
For character sets and collation where character to weight mapping > 1,
there we need to make sure while creating a sort key,
a temporary buffer is created to store the value of the item by val_str function
and then copy that value back to the sort buffer.
In this case when using a priority queue Sort_param::tmp_buffer was not allocated.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Field::maybe_null
For field with type INET, during EITS collection the min and max values are store in text
representation in the statistical table.
While retrieving the value from the statistical table, the value is stored back in the original
field using binary form instead of text and this was resulting in the crash.
Introduced 2 functions in the Field structure:
1) store_to_statistical_minmax_field
2) store_from_statistical_minmax_field
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test was disabled in a135f0ab88d63b9a8976d6b3010f27766c38873d, but
accidentally reverted during the merge in
https://github.com/MariaDB/server/compare/0186b0a07760...b30a01314217
Because it was a 3-way merge, the removal is not directly visible.
It can be verified manually though:
Line not changed:
git diff a135f0ab88d6..0186b0a07760 mysql-test/unstable-tests
Line removed:
git diff a135f0ab88d6..b30a01314217 mysql-test/unstable-tests
This commit fixes the Travis-CI build and makes the main 10.5 git branch
green again on Travis-CI (and whatever else build environment that also
is failing due to this test).
Related: MDEV-22592
|
|
|
|
|
|
| |
The buildbot.askmonty.org has explicit tests that check that this file
exists, thus to get tests pass, an empty placeholder must be created.
Remove this once CI has been updated not to expect this file.
|
|
|
|
|
|
|
|
|
|
| |
We can't expect that users want to always convert their mysqld_safe
settings on an upgrade. In its current form it will always run, and that
seems unnecessary on every single installation.
Also the script is buggy, leaks mysqld_safe output into the written file
and since it gets syntax errors the whole mariadb.service will fail to
work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These do now show up automatically due to init and systemd customizations,
so the handiest fix is to add them manually. This has been the praxis
in downstream MariaDB packaging for a couple years now, and works fine.
- Ensure service is loaded and started after installation,
(fixes service start issues in Debian/Ubuntu upgrades where
otherwise service mysql status stayed stopped)
- Ensure service stopped before removal/purge
(fixes unstopped processes detected by piuparts)
- Ensure systemd daemon is reloaded after removal/purge when service
has been removed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Partially reverts commit a4cc6fb91f3855e0ed803a6e1762440cfcf8cb5c.
While all current versions of Linux have systemd, support for traditional
init.d is still needed e.g. on Linux subsystem on Windows, kFreeBSD and
special variants of Debian/Ubuntu that for other reasons don't have
systemd.
Thus, re-introduce the init file that was remove, but this time with
then name 'mariadb'.
Supporting traditional sysv init in paraller with systemd is easy, since
Debian has facilities for it.
Also simplify and update salsa-ci.yml install/upgrade testing works
for all previous MariaDB and MySQL releases without any excess quirks.
Note that in fresh installs the salsa-ci.yml needs to run command
'service mariadb status' to control the service, while on upgrades
it is enough to run 'service mysql status', since the init.d/mysql
file is left behind from previous install, along with some other
config files such as /etc/default/mysql and /etc/mysql/* stuff.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unaligned memory
Apparently, in stats_reset_table(), the innocuous
memset(&group->counters, 0, sizeof(group->counters));
is converted by clang to SSE2 instructions.
The problem is that "group" is not correctly aligned,
despite MY_ALIGNED(CPU_LEVEL1_DCACHE_LINESIZE) in the thread_group_t
declaration.
It is not aligned because it was allocated with my_malloc, since
commit fd9f1638, MDEV-5205. Previously all_groups was a
statically allocated array.
Fix is to remove MY_ALIGNED, and pad the struct instead.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Same array instance in two Item_func_in instances. First Item_func_in
instance is freed on table close. Second one is freed on
cleanup_after_query().
get_copy() depends on copy ctor for copying an item and hence does
shallow copy for default copy ctor. Use build_clone() for deep copy of
Item_func_in.
|
| |
| |
| |
| |
| | |
Most of the volations came from:
sel_arg_range_seq_next(void*, st_key_multi_range*) (opt_range_mrr.cc:342)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
lock_trx_handle_wait_low
Problem was that trx->lock.was_chosen_as_wsrep_victim variable was
not set back to false after it was set true.
wsrep_thd_bf_abort
Add assertions for correct mutex status and take necessary
mutexes before calling thd->awake_no_mutex().
innobase_rollback_trx()
Reset trx->lock.was_chosen_as_wsrep_victim
wsrep_abort_slave_trx()
Removed unused function.
wsrep_innobase_kill_one_trx()
Added function comment, removed unnecessary parameters
and added debug assertions to enforce correct usage. Added
more debug output to help out on error analysis.
wsrep_abort_transaction()
Added debug assertions and removed unused variables.
trx0trx.h
Removed assert_trx_is_free macro and replaced it with
assert_freed() member function.
trx_create()
Use above assert_free() and initialize wsrep variables.
trx_free()
Use assert_free()
trx_t::commit_in_memory()
Reset lock.was_chosen_as_wsrep_victim
trx_rollback_for_mysql()
Reset trx->lock.was_chosen_as_wsrep_victim
Add test case galera_bf_kill
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
is not in MSI
When server is compiled with recent VS2019, then executables,
have dependency on vcruntime140_1.dll
While we include the VC redistributable merge modules into our MSI package,
those merge modules were stale (taken from older VS version, 2017)
Since VS2019 brough new DLL dependency by introducing new exception handling
https://devblogs.microsoft.com/cppblog/making-cpp-exception-handling-smaller-x64
thus the old MSMs were not enough.
The fix is to change logic in win/packaging/CMakeLists.txt to look up for
the correct, new MSMs.
The bug only affects 10.4,as we compile with static CRT before 10.4,
and partly-statically(just vcruntime stub is statically linked, but not UCRT)
after 10.4
For the fix to work, it required also some changes on the build machine
(vs_installer, modify VS2019 installation, add Individual Component
"C++ 2019 Redistributable MSMs")
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit c675886dcdecd29571bd08605a409325ee81004c.
The bug was introduced in e3f5789ac0b and fixed in 1af74d523a7
The option was introduced between those two commits and now it's
redundant again.
|
|\ \
| |/ |
|
| |\ |
|
| | |\ |
|
| | | |\ |
|
| | | | |\ |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Let us limit the maximum value of the debug parameter
innodb_data_file_size to 256 MiB. It is only being used
in the test innodb.log_data_file_size, and the size
of the system tablespace should never exceed some 70 MiB
in ./mtr. Thus, 256 MiB should be a reasonable limit.
The fact that negative values that are passed to unsigned parameters
wrap around to the maximum value appears to be a regression due to
commit 18ef02b04dfae21148c7397d088c7ffdfcd23c4e
and has been filed as bug MDEV-22219.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The InnoDB insert buffer was upgraded in MySQL 5.5 into a change
buffer that also covers delete-mark and delete (purge) operations.
There is an important constraint for delete operations: a B-tree
leaf page must not become empty unless the entire tree becomes empty,
consisting of an empty root page. Because change buffer merges only
occur on a single leaf page at a time, delete operations must not be
buffered if it is possible that the last record of the page could be
deleted. (In that case, we would refuse to use the change buffer, and
if we really delete the last record, we would shrink the index tree.)
The function ibuf_get_volume_buffered_hash() is part of our insurance
that the page would not become empty. It is supposed to map each
buffered INSERT or DELETE_MARK record payload into a hash value.
We will only count each such record as a distinct key if there is no
hash collision. DELETE operations will always decrement the predicted
number fo records in the page.
Due to a bug in the function, we would actually compute the hash value
not only on the record payload, but also on some following bytes,
in case the record contains NULL values. In MySQL Bug #61104, we had
some examples of this dating back to 2012. But back then, we failed to
reproduce the bug, and in commit d84c95579ba1eca2f9bf5b0be9f14040e4441227
we simply demoted the hard assertion to a message printout and a debug
assertion failure.
ibuf_get_volume_buffered_hash(): Correctly compute the hash value
of the payload bytes only. Note: we will consider
('foo','bar'),(NULL,'foobar'),('foob','ar') to be equal, but this
is not a problem, because in case of a hash collision, we could
also consider ('boo','far') to be equal, and underestimate the number
of records in the page, leading to refusing to buffer a DELETE.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
line 1."
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Flush LSN to system tablespace on innodb shutdown if XA is rolled back by
mariabackup.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
innobase_get_charset(), innobase_get_stmt_safe(): Remove.
It is more efficient and readable to invoke thd_charset()
and thd_query_safe() directly, without a non-inlined wrapper function.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The function thd_query_safe() is used in the implementation of the
following INFORMATION_SCHEMA views:
information_schema.innodb_trx
information_schema.innodb_locks
information_schema.innodb_lock_waits
information_schema.rocksdb_trx
The implementation of the InnoDB views is in trx_i_s_common_fill_table().
This function invokes trx_i_s_possibly_fetch_data_into_cache(),
which will acquire lock_sys->mutex and trx_sys->mutex in order to
protect the set of active transactions and explicit locks.
While holding those mutexes, it will traverse the collection of
InnoDB transactions. For each transaction, thd_query_safe() will be
invoked.
When called via trx_i_s_common_fill_table(), thd_query_safe()
is acquiring THD::LOCK_thd_data while holding the InnoDB locks.
This will cause a deadlock with THD::awake() (such as executing
KILL QUERY), because THD::awake() could invoke lock_trx_handle_wait(),
which attempts to acquire lock_sys->mutex while already holding
THD::lock_thd_data.
thd_query_safe(): Invoke mysql_mutex_trylock() instead of
mysql_mutex_lock(). Return the empty string if the mutex
cannot be acquired without waiting.
|
| | | |\ \ \ |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
As part of the SPATIAL INDEX implementation in InnoDB,
dict_index_t was expanded by a rtr_ssn_t field. There are only
3 operations for this field, all protected by rtr_ssn_t::mutex:
* btr_cur_search_to_nth_level() stores the least significant 32 bits
of the 64-bit value that is stored in the index root page.
(This would better be done when the table is opened for the
very first time.)
* rtr_get_new_ssn_id() increments the value by 1.
* rtr_get_current_ssn_id() reads the current value.
All these operations can be implemented equally safely by using
atomic memory access operations.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
to server
correct the help text
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Enable tests with additional galera output to find out actual
reason for test failures.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
galera.galera_as_slave_gtid_myisam: Result length mismatch
Add wait_condition so that drop table has time to replicate to
Galera cluster.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The test was incompatible with ./mtr --repeat=2 until
commit 2d6719d7ee92843d5b0b9a27c7deaff5cacd4745
fixed that.
It turns out that the failing assertion that we disabled in
commit 3db94d2403c1f2791bddd43656d7b0d6320b453d
is bogus and can fail when the change buffer is emptied
during the last batch of crash recovery. The reason for this
is the condition around the page_create_empty() call in
page_cur_delete_rec(). The condition was removed in MariaDB
Server 10.5 as part of MDEV-12353, in
commit 7ae21b18a6b73bbc3bf1ff448faf60c29ac1d386 and
commit f8a9f906679e1d1ab026c245f7d24c652050d8b3.
The bug that the assertion aimed to catch is MDEV-22497, which
was fixed in commit 26aab96ecfc9eca647ab9d5b4be3ba5823df4cde.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
galera.galera_wsrep_new_cluster: Result content mismatch
Test starts two servers and we do not know order they really start,
thus wsrep_local_index can be 1 or 2.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Test seems to work.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixing a race condition while collecting the engine independent statistics.
Thread1>
1) start running "ANALYZE TABLE t PERISTENT FOR COLUMNS (..) INDEXES ($list)"
2) Walk through $list and save it in TABLE::keys_in_use_for_query
3) Close/re-open tables
Thread2>
1) Make some use of table t. This involves taking table t from
the table cache, and putting it back (with TABLE::keys_in_use_for_query reset to 0)
Thread1>
continue collecting EITS stats. Since TABLE::keys_in_use_for_query is set to 0 we
will not collect statistics for indexes in $list.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
commit 6495806e59cc27313375fa8d431b7b8e777f73ff removed all reads
of buf_page_t::write_size. Let us remove the field altogether.
|
| | |\ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Make LATERAL DERIVED tables visible in EXPLAIN FORMAT=JSON output.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Type_handler_xxx::Item_const_eq() can handle only non-NULL values.
The code in Item_basic_value::eq() did not take this into account.
Adding a test to detect three different combinations:
- Both values are NULLs, return true.
- Only one value is NULL, return false.
- Both values are not NULL, call Type_handler::Item_const_eq()
to check equality.
|
| |\ \ \ \ \ \ \ |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Focal
Not only Ubuntu Focal builds openssl with OPENSSL_TLS_SECURITY_LEVEL=2,
but for some unfathomable reason it patches openssl sources to disable
TLS < 1.2 at security level 2, even though openssl manual says it
should only happen at level 4:
https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_set_security_level.html
We test TLSv1.1 and TLSv1, so we have to override Focal defaults in mtr.
|