galera_sr.GCF-1060 'innodb' w2 [ fail ] timeout after 900 seconds
galera_3nodes.galera_ssl_reload At line 50: mysql_shutdown failed
galera_3nodes.galera_ssl_reload : MDEV-30172 At line 50: mysql_shutdown failed
galera_3nodes.GCF-354 : mysqltest: At line 39: query 'DROP TABLE test.t1' failed: 1047: WSREP has not yet prepared node for application use
galera_3nodes.GCF-354 : mysqltest: At line 30: query 'INSERT INTO test.t1 values (1)' failed: 1180: Got error 6 "No such device or address"
galera_wan : [ERROR] WSREP: /home/buildbot/buildbot/build/gcs/src/gcs_state_msg.cpp:gcs_state_msg_get_quorum():947: Failed to establish quorum.
Merge Jan's bb-10.6-merge-jan branch:
MDEV-30172 Galera test case cleanup
* Delete tests that are not supported and not going to be supported
any time soon
* Fix result set on tests that are not run on bb
* Fix tests that fail because of auto increment offset
* Make sure that disabled tests have open bug report
Hide the errors related to missing innodb stats tables in bootstrap mode
on the assumption that because we are in bootstrap mode they are going
to be created.
mtr_t::commit_file(): Protect the rename operation with fil_system.mutex
like we used to do before commit 2e43af69e3
in order to prevent fil_node_open_file() from running concurrently.
In other words, fil_system.mutex will protect the consistency of
fil_node_t::name and the file name in the file system.
This race condition should be very hard to trigger. We would need
a low value of innodb_open_files or table_cache limit so that
fil_space_t::try_to_close() will be invoked frequently. Simultaneously
with a RENAME operation, something (such as a write of a data page)
would have to try to open the file.
trx_purge_truncate_history(): In case of an apparent conflict with
buf_pool_t::release_freed_page(), always momentarily acquire
buf_pool.mutex, to let the thread that is holding it and waiting for
buf_pool.flush_list_mutex to proceed.
The fix in commit c410f7aaea was
insufficient, because simple yielding would not necessarily let
the conflicting thread to acquire buf_pool.flush_list_mutex.
This hang was reported and the fix tested by Axel Schwenke.
This commit fixes the test system hanging due to
the galera_var_notify_ssl_ipv6 test and also brings
the wsrep_notify[_ssl].sh files in line with each other
between the user template and the mtr suite.
Quotes are also added here to avoid problems if the
user specifies the value of one of the variables at the
beginning of the file containing shell-specific characters,
for example, if the password or username specified in the
PSWD and USER variables will contain the "$" character.
Also fixed an issue with automatic --ssl-verify-server-cert
option substitution when the corresponding value is set
by the user to "1" or "on".
Also fixed some tests here to avoid joining one of the nodes
to another cluster when the nodes are restarted from the mtr
side, which can lead to random failures when testing with
buildbot.
This commit fixes the test system hanging due to
the galera_var_notify_ssl_ipv6 test and also brings
the wsrep_notify[_ssl].sh files in line with each other
between the user template and the mtr suite.
Quotes are also added here to avoid problems if the
user specifies the value of one of the variables at the
beginning of the file containing shell-specific characters,
for example, if the password or username specified in the
PSWD and USER variables will contain the "$" character.
Also fixed an issue with automatic --ssl-verify-server-cert
option substitution when the corresponding value is set
by the user to "1" or "on".
Also fixed some tests here to avoid joining one of the nodes
to another cluster when the nodes are restarted from the mtr
side, which can lead to random failures when testing with
buildbot.
mysql_discard_or_import_tablespace(): On successful
ALTER TABLE...DISCARD TABLESPACE, evict the table handle from the
table definition cache, so that ha_innobase::close() will be invoked,
like InnoDB expects to be the case. This will avoid an assertion failure
ut_a(table->get_ref_count() == 0) during IMPORT TABLESPACE.
ha_innobase::open(): Do not issue any ER_TABLESPACE_DISCARDED warning.
Member functions for DML will do that.
ha_innobase::truncate(), ha_innobase::check_if_supported_inplace_alter():
Issue ER_TABLESPACE_DISCARDED warnings, to compensate for the removal of
the warning in ha_innobase::open().
row_quiesce_write_indexes(): Only write information about committed
indexes. The ALTER TABLE t NOWAIT ADD INDEX(c) in the nondeterministic
test case will most of the time fail due to a metadata lock (MDL) timeout
and leave behind an uncommitted index.
Reviewed by: Sergei Golubchik
The geometry type requires Type:"Feature" but the feature need
not be first in the JSON structure.
Adjust code to return an error if geometry isn't a JSON object,
but continue parsing searching for Type: "Feature" to trigger
the geometry parsing.
Thanks Derick Magnusen for the bug report.
Convert minimal amount of Lintian overrides to make Lintian
test pass also with Debian Sid latest Lintian 2.115 version.
Old style overrides are kept so they can be used with
older versions of Lintian.
Introduce minimal Lintian overrides which are common
from MariaDB version 10.5 up-to to 10.8.
Overrides added files:
* debian/mariadb-test-data.lintian-overrides
- MariaDB installs some shared objects to test-suite directory and not in
'/usr/lib' or similar. Share objects is pam_mariadb_mtr.so. Tags are
arch-dependent-file-in-usr-share and
arch-independent-package-contains-binary-or-object Lintia
* debian/mariadb-test.lintian-overrides
- MariaDB installs some some binaries to test-sute directory and
in mariadb-test package they are my_safe_process and
wsrep_check_version. Tags is
arch-dependent-file-in-usr-share
* debian/source/lintian-overrides
- In source there is some source files missing which should be addressed
sql/share/charsets/languages.html and
and storage/rocksdb/rocksdb/docs/_includes/footer.html.
Tags is source-is-missing
- Add Lintian override for missing:
storage/columnstore/columnstore/utils/jemalloc/libjemalloc.so.2
- Add Lintian override for substvar external resources:
${source:Version} libmariadb-dev -> libmysqlclient-dev [debian/control:66]
${source:Version} libmariadb-dev -> libmysqld-dev [debian/control:66]
${source:Version} libmariadbd-dev -> libmariadbclient-dev [debian/control:216]
If the backup finished in the middle of a Aria bulk load insert,
which could happen with LOAD DATA INFILE, CREATE ... SELECT etc)
there was a chance that Aria recovery would fail on the backup.
Fixed by ensuring that bulk load operations for Aria are not allowed
under BACKUP LOCK.
I also changed so that the table TRN is updated just before truncate
which ensures that old redo's for the table are ignored.
I also enabled Aria redo for DDL's to be able to repeat REPAIR commands.
Without this change recovery would not work on repaired tables.
Notes:
- We take the backup lock protection at the end of bulk insert (as we
don't want to keep the lock over a very long running insert).
If mariadb-backup keeps the backup lock too long, this may fail with
a lock timeout. In this case the batch insert will fail and the table
will be truncated (set to it's original state).
The bug is caused by a similar mechanism as MDEV-21027.
The function, check_insert_or_replace_autoincrement, failed to open
all the partitions on REPLACE SELECT statements and it results in the
assertion error.
* Delete tests that are not supported and not going to be supported
any time soon
* Fix result set on tests that are not run on bb
* Fix tests that fail because of auto increment offset
* Make sure that disabled tests have open bug report
btr_cur_t::open_random_leaf(): Replaces btr_cur_open_at_rnd_pos().
Acquire a shared latch on each page, and finally release all
latches except the one on the leaf page.
This fixes a race condition between the purge of history and
btr_estimate_number_of_different_key_vals(), which turned out
to only hold a buffer-fix on the randomly chosen leaf page.
Typically, an assertion would fail in page_rec_is_supremum().
ibuf_contract(): Start from the beginning of the change buffer,
to simplify the logic. Starting with
commit b42294bc64
it does not matter much where the change buffer merge is being initiated.
The race condition may have been introduced as early as
mysql/mysql-server@ac74632293
from where it was copied to
commit 2e814d4702.
Reviewed by: Vladislav Lesin
Tested by: Matthias Leich
