| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
The default value for eq_range_index_dive_limit is set to 10
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* fix CRL tests to work
* regenerate certificates to be at least 2048 bit
(fixes buster and rhel8 in buildbot)
* update generate-ssl-cert.sh to generate crl files
* make all SSL tests to use certificates generated
in generate-ssl-cert.sh, remove unused certificates
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
fill_status.
Also, remove LOCK_status around calc_sum_of_all_status()
Also, rename LOCK_show_status into LOCK_all_status_vars.
This reflects the variable the lock protects.
|
|/
|
|
|
|
|
|
|
|
|
| |
LOG_INFO::lock was useless. It could've only protect against concurrent
iterators execution, which was already protected by LOCK_thread_count.
Use LOCK_thd_data instead of LOCK_thread_count as a protection against
THD::current_linfo reset.
Aim is to reduce usage of LOCK_thread_count and COND_thread_count.
Part of MDEV-15135.
|
|\ |
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
row_upd_sec_step upon DELETE after UPDATE failed due to FK violation
The idea of the fix: reset state from previous query.
row_upd_clust_step(): reset cached index before updating a clustered index
Closes #1133
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add a simplest regression test. Specifically, I want to be sure that
SYS_COLUMNS.LEN is increased.
Closes #1123
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently, the three-node mtr suite for Galera (galera_3nodes)
uses a separate IPv6 availability check using the "have_ipv6.inc"
file. This check duplicates a more accurate check at suite.pm
level, which can be used by including the file "check_ipv6.inc".
This patch removes this discrepancy between suites. In addition,
one of the files in the galera_3nodes suite does not contain the
option "--bind-address=::" which is needed for the test to work
correctly with IPv6 (at least on some systems), since without
it the server will not wait for connections on the IPv6 interface.
https://jira.mariadb.org/browse/MDEV-18379
|
| | |
| | |
| | |
| | |
| | |
| | | |
failed in ha_innobase::open
Closes #1134
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Made galera_3nodes.galera_ipv6_mariabackup deterministic with respect
to donor selection, fixed assert grep definitions to match
Galera 4 behavior and recorded.
* Removed extra connection setup from galera_3nodes.galera_ipv6_mysqldump
and recorded.
|
| | | |
|
|\ \ \
| |/ / |
|
| |\ \
| | |/ |
|
| | |\ |
|
| | | |\ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
nominated as PK
Problem:
========
Server fails to notify the engine by not setting the ADD_PK_INDEX and
DROP_PK_INDEX When there is a
i) Change in candidate for primary key.
ii) New candidate for primary key.
Fix:
====
Server sets the ADD_PK_INDEX and DROP_PK_INDEX while doing alter for the
above problematic case.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
32 bit int
Row-based slave applier could not parse correctly the table id when
the value exceeded the max of 32 bit unsigned int.
The reason turns out in that the being parsed value placeholder
was sized as 4 bytes.
The type is fixed to ulonglong.
Additionally the patch works around Rows_log_event::m_table_id 4 bytes
size on 32 bits platforms. In case of last_table_id value overflows
the 4 byte max, there won't be the zero value for m_table_id generated
and the first wrapped-around value is one, this is thanks to excluding
UINT_MAX32 + 1 from TABLE_SHARE::table_map_id.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
remove tests that rely on specific execution order
|
| | | | |
| | | | |
| | | | |
| | | | | |
remove tests that rely on specific execution order
|
| | | |\ \
| | | | | |
| | | | | | |
MDEV-17421: mtr does not restart the server whose parameters were changed
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If a mtr test runs multiple servers and only some of them get
restarted on whatever reason with new command-line parameters,
then subsequent mtr test may fail, because no cleanup is performed.
Replication and Galera test suites are affected.
In the mtr script, there is a server_need_restart function
that decides whether we need to start a new mysqld process before
the new (next) test. If the mysqld parameters were changed in the
previous test - not necessarily the parameters of the primary mysqld
server, maybe even the secondary server parameters - this function
decides to start a new mysqld process. But since it does not remove
the old (changed) parameters, the new process starts with the
parameters changed by the *previous* test.
To correct this error, we must delete the modified process
parameters after checking that they have been changed during
the previous test.
This patch also simplifies and makes more stable the
galera_drop_database test, during debugging of which this
problem was detected.
https://jira.mariadb.org/browse/MDEV-17421
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Thanks to commit 2614a0ab0ffd802b3b9e62795979e83b6a10fcb3
before MDEV-5800, no version of MariaDB is affected by this bug
that was fixed in MySQL 5.7.25.
|
| | |\ \ \ \
| | | |/ / / |
|
| | | |\ \ \
| | | | | |/
| | | | |/| |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
on startup innodb is checking whether files "ib_logfileN"
(for N from 1 to 100) exist, and whether they're readable.
A non-existent file aborted the scan.
A directory instead of a file made InnoDB to fail.
Now it treats "directory exists" as "file doesn't exist".
|
| |\ \ \ \ \
| | | | | | |
| | | | | | | |
MDEV-17835: Remove wsrep-sst-method=xtrabackup
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The second line of changes related to replacing xtrabackup with
mariabackup:
1) All unnecessary references to xtrabackup are removed from
the documentation, from some comments, from the control files
that are used to prepare the packages.
2) Made corrections of the tests from the galera_3nodes suite
that mentioned xtrabackup or the old (associated with xtrabackup)
version of innobackupex.
3) Fixed flaws in the galera_3nodes mtr suite control scripts,
because of which they could not work with mariabackup.
4) Fixed numerous bugs in the SST scripts and in the mtr test
files (galera_3nodes mtr suite) that prevented the use of Galera
with IPv6 addresses.
5) Fixed flaws in tests for rsync and mysqldump (for galera_3nodes
mtr tests suite). These tests were not performed successfully without
these fixes.
https://jira.mariadb.org/browse/MDEV-17835
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
dict_table_t::prepare_instant(): Correctly assign instantly
dropped columns to instant->dropped[].
|
|\ \ \ \ \ \ \
| |/ / / / / / |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
btr_pcur_store_position
MDEV-11369 (instant ADD COLUMN) introduced a regression in the case the
leftmost leaf page of the clustered index is empty except for the
hidden metadata record.
btr_pcur_store_position(): If the only record in the leftmost leaf page
is the metadata record, store the position before the first user record
in the tree.
|
|\ \ \ \ \ \ \
| |/ / / / / / |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
InnoDB does not allow creating multiple FULLTEXT INDEX
in ALGORITHM=INPLACE. This constraint was not being properly
enforced after MariaDB started to support ALGORITHM=INSTANT
and instant ADD COLUMN.
As a side effect of this bug, we again allow ALGORITHM=INPLACE
to rebuild a table when one FULLTEXT INDEX survives.
Also, we are returning a more accurate reason for refusing LOCK=NONE.
innobase_fulltext_exist(): Return the number of fulltext indexes.
ha_innobase::check_if_supported_inplace_alter(): If the table
needs to be rebuilt, refuse the operation if multiple fulltext
indexes would remain.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
commit_cache_norebuild(): Restore the MDEV-17901 fix that was reverted
as part of the MDEV-18076/MDEV-18077 fix. It was not redundant after all.
|
|\ \ \ \ \ \ \
| |/ / / / / / |
|
| |\ \ \ \ \ \
| | | |/ / / /
| | |/| | | | |
|
| | |\ \ \ \ \
| | | | |/ / /
| | | |/| | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | |\ \ \ \
| | | | | |/ /
| | | | |/| | |
|