summaryrefslogtreecommitdiff
path: root/mysql-test
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-22596: DELETE FOR PORTION does not obey "Expression in FOR PORTION OF ↵Nayuta Yanagisawa2020-10-152-0/+9
| | | | | | | | | | 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.
* MDEV-16664: Remove innodb_lock_schedule_algorithmbb-10.6-MDEV-16664Marko Mäkelä2020-10-0511-286/+0
| | | | | | | | | | | | | | | | | | | 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).
* Merge 10.5 into 10.6Marko Mäkelä2020-09-24171-1326/+2938
|\
| * Merge 10.4 into 10.5Marko Mäkelä2020-09-2382-392/+867
| |\
| | * Merge 10.3 into 10.4Marko Mäkelä2020-09-2212-8/+98
| | |\
| | | * Merge 10.2 into 10.3Marko Mäkelä2020-09-2212-8/+94
| | | |\
| | | | * Merge 10.1 into 10.2Marko Mäkelä2020-09-2212-8/+94
| | | | |\
| | | | | * MDEV-21839: Handle crazy offset to SHOW BINLOG EVENTSSujatha2020-09-163-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ======= SHOW BINLOG EVENTS FROM <"random"-pos> caused a variety of failures as reported in MDEV-18046. They are fixed but that approach is not future-proof as well as is not optimal to create extra check for being constructed event parameters. Analysis: ========= "show binlog events from <pos>" code considers the user given position as a valid event start position. The code starts reading data from this event start position onwards and tries to map it to a set of known events. Each event has a specific event structure and asserts have been added to ensure that, read event data, satisfies the event specific requirements. When a random position is supplied to "show binlog events command" the event structure specific checks will fail and they result in assert. For example: https://jira.mariadb.org/browse/MDEV-18046 In the bug description user executes CREATE TABLE/INSERT and ALTER SQL commands. When a crazy offset like "SHOW BINLOG EVENTS FROM 365" is provided code assumes offset 365 as valid event begin and proceeds to EVENT_LEN_OFFSET reads some random length and comes up with a crazy event which didn't exits in the binary log. In this quoted example scenario, event read at offset 365 is considered as "Update_rows_log_event", which is not present in binary log. Since this is a random event its validation fails and code results in assert/segmentation fault, as shown below. mysqld: /data/src/10.4/sql/log_event.cc:10863: Rows_log_event::Rows_log_event( const char*, uint, const Format_description_log_event*): Assertion `var_header_len >= 2' failed. 181220 15:27:02 [ERROR] mysqld got signal 6 ; #7 0x00007fa0d96abee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x000055e744ef82de in Rows_log_event::Rows_log_event (this=0x7fa05800d390, buf=0x7fa05800d080 "", event_len=254, description_event=0x7fa058006d60) at /data/src/10.4/sql/log_event.cc:10863 #9 0x000055e744f00cf8 in Update_rows_log_event::Update_rows_log_event Since we are reading random data repeating the same command SHOW BINLOG EVENTS FROM 365 produces different types of crashes with different events. MDEV-18046 reported 10 such crashes. In order to avoid such scenarios user provided starting offset needs to be validated for its correctness. Best way of doing this is to make use of checksums if they are available. MDEV-18046 fix introduced the checksum based validation. The issue still remains in cases where binlog checksums are disabled. Please find the following bug reports. MDEV-22473: binlog.binlog_show_binlog_event_random_pos failed in buildbot, server crashed in read_log_event MDEV-22455: Server crashes in Table_map_log_event, binlog.binlog_invalid_read_in_rotate failed in buildbot Fix: ==== When binlog checksum is disabled, perform scan(via reading event by event), to validate the requested FROM <pos> offset. Starting from offset 4 read the event_length of next_event in the binary log. Using the next_event length advance current offset to point to next event. Repeat this process till the current offset is less than or equal to crazy offset. If current offset is higher than crazy offset provide appropriate invalid input offset error.
| | | | | * mtr: main.mysql_upgrade - record after correcting error messageDaniel Black2020-09-141-2/+2
| | | | | |
| | | | | * MDEV-17438 rpl.show_status_stop_slave_race-7126 fails with timeout on WindowsSachin2020-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem:- Test case uses socket which does not work on windows, So mysqlslap falls back to default connection which is defined in my.cnf and connects to master instead of slave. Since start slave/stop slave is executed on master we get error MASTER_HOST was not set Solution:- Use Port instead of socket
| | | | | * MDEV-9501: rpl.rpl_binlog_index, rpl.rpl_gtid_crash, rpl.rpl_stm_multi_query ↵Sujatha2020-09-074-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fail sporadically in buildbot with Master command COM_REGISTER_SLAVE failed Analysis: ======== Slave server will send COM_REGISTER_SLAVE command at the time of establishing a connection to master. If master is down, then the command will fail and COM_REGISTER_SLAVE failed warning is reported. 'rpl_binlog_index.test' shutsdown the master and it relocates binary logs to a new location and attempts to start master by pointing 'log-bin' to new location. During this process the slave threads are active. IO thread actively checks for the presence of master when it finds that the connection is lost it attempts a reconnect, as master is down COM_REGISTER_SLAVE command fails. As part of fix, stop the slave threads and then shutdown the master and do the binlog relocation. Once master is restarted start the slave threads and sync them with the master. In test binary logs and index files on master are relocated to /tmpdir but during master restart only --log-bin option is provided, this is incorrect. Even --log-bin-index also should be pointed to /tmpdir otherwise upon master server restart two index files will be created. One master-bin.index in /tmpdir and a new master-bin.index as per log_basename in datadir. Due to this slave will fail to connect to master. 'rpl_gtid_crash.test' tests following scenario "crashing master, causing slave IO thread to reconnect while SQL thread is running". When IO thread tries to connect to crashed master on slow platforms COM_REGISTER_SLAVE command fails. This is expected hence the warning should be added to suppression list.
| | | | | * MDEV-23535 SIGSEGV, SIGABRT and SIGILL in typeinfo for ↵Alexander Barkov2020-09-034-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_func_set_collation (on optimized builds) This piece of the code in Item_func_or_sum::agg_item_set_converter: if (!conv && ((*arg)->collation.repertoire == MY_REPERTOIRE_ASCII)) conv= new (thd->mem_root) Item_func_conv_charset(thd, *arg, coll.collation, 1); was wrong because: 1. It could change Item_cache to Item_func_conv_charset (with the old Item_cache in args[0]). Such Item type change is not always supported, e.g. the code in Item_singlerow_subselect::reset() expects only Item_cache, to be able to call Item_cache::set_null(). So it erroneously reinterpreted Item_func_conv_charset to Item_cache and called a non-existing method set_null(), which crashed the server. 2. The 1 in the last parameter to Item_func_conv_charset() was also a problem. In MariaDB versions where the reported query did not crash, it erroneously returned "empty set" instead of one row, because the 1 made subselects execute too earlier and return NULL. Fix: 1. Removing the above two lines from Item_func_or_sum::agg_item_set_converter() 2. Adding the repertoire test inside the constructor of Item_func_conv_charset, so it now detects itself as "safe" in more cases than before. This is needed to avoid new "Illegal mix of collations" after removing the wrong code in various scenarios when character set conversion from pure ASCII happens, including the reported scenario. So now this sequence: Item_cache -> Item_func_concat is replaced to this compatible sequence (the top Item is still Item_cache): new Item_cache -> Item_func_conv_charset -> Item_func_concat Before the fix it was replaced to this incompatible sequence: Item_func_conv_charset -> old Item_cache -> Item_func_concat
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-09-227-4/+43
| | |\ \ \ \ | | | |/ / /
| | | * | | Merge 10.2 into 10.3Marko Mäkelä2020-09-227-4/+43
| | | |\ \ \ | | | | |/ /
| | | | * | MDEV-22939 Server crashes in row_make_new_pathname()Marko Mäkelä2020-09-222-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The statement ALTER TABLE...DISCARD TABLESPACE is problematic, because its designed purpose is to break the referential integrity of the data dictionary and make a table point to nowhere. ha_innobase::commit_inplace_alter_table(): Check whether the table has been discarded. (This is a bit late to check it, right before committing the change.) Previously, we performed this check only in a specific branch of the function commit_set_autoinc(). Note: We intentionally allow non-rebuilding ALTER TABLE even if the tablespace has been discarded, to remain compatible with MySQL. (See the various tests with "wl5522" in the name, such as innodb.innodb-wl5522.) The test case would crash starting with 10.3 only, but it does not hurt to minimize the code and test difference between 10.2 and 10.3.
| | | | * | MDEV-23776: Re-apply the fix and make the test more robustMarko Mäkelä2020-09-223-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test that was added in commit e05650e6868eab2dbb9f58c4786bcc71afc4ffce would break a subsequent run of a test encryption.innodb-bad-key-change because some pages in the system tablespace would be encrypted with a different key. The failure was repeatable with the following invocation: ./mtr --no-reorder \ encryption.create_or_replace,cbc \ encryption.innodb-bad-key-change,cbc Because the crash was unrelated to the code changes that we reverted in commit eb38b1f703fb84299680f9c5a75ea970be7aee1d we can safely re-apply those fixes.
| | | | * | MDEV-23705 Assertion 'table->data_dir_path || !space'Marko Mäkelä2020-09-222-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After DISCARD TABLESPACE, the tablespace of a table will no longer exist, and dict_get_and_save_data_dir_path() would invoke dict_get_first_path() to read an entry from SYS_DATAFILES. For some reason, DISCARD TABLESPACE would not to remove the entry from there. dict_get_and_save_data_dir_path(): If the tablespace has been discarded, do not bother trying to read the name. Side note: The tables SYS_TABLESPACES and SYS_DATAFILES are redundant and subject to removal in MDEV-22343.
| | * | | | MDEV-23659 : Update Galera disabled.def fileJan Lindström2020-09-221-2/+0
| | | | | |
| | * | | | MDEV-21170 : Galera test failure on galera_sr.GCF-1043[A|B]Jan Lindström2020-09-224-68/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add error printout when mysql.wsrep_streaming_log lock fails. However, tests are very undeterministic and not suitable for mtr environment. Thus, they are removed.
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-09-218-87/+224
| | |\ \ \ \ | | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We omit commit a3bdce8f1e268e3ac57644faf91c9c5ad43f5291 and commit a0e2a293bcc25fb10888fd00bd63bce04c195524 because they would make the test galera_3nodes.galera_gtid_2_cluster fail and disable it.
| | | * | | Merge 10.2 into 10.3Marko Mäkelä2020-09-2112-91/+315
| | | |\ \ \ | | | | |/ /
| | | | * | MDEV-23776: Add the reduced encryption.create_or_replace testMarko Mäkelä2020-09-212-0/+101
| | | | | | | | | | | | | | | | | | | | | | | | This was forgotten in commit a9d8f5c1a55e03312211c637a1a916cc57573a73.
| | | | * | MDEV-23776: Split encryption.create_or_replaceMarko Mäkelä2020-09-213-65/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let us shrink the test encryption.create_or_replace so that it can run on the CI system, also on the embedded server. encryption.create_or_replace_big: Renamed from the original test, with the subset of encryption.create_or_replace omitted.
| | | | * | MDEV-23659 : Update Galera disabled.def fileJan Lindström2020-09-211-0/+1
| | | | | |
| | | | * | Fix try.Jan Lindström2020-09-213-5/+91
| | | | | |
| | | | * | MDEV-23711 make mariabackup innodb redo log read error message more clearVlad Lesin2020-09-213-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | log_group_read_log_seg() returns error when: 1) Calculated log block number does not correspond to read log block number. This can be caused by: a) Garbage or an incompletely written log block. We can exclude this case by checking log block checksum if it's enabled(see innodb-log-checksums, encrypted log block contains checksum always). b) The log block is overwritten. In this case checksum will be correct and read log block number will be greater then requested one. 2) When log block length is wrong. In this case recv_sys->found_corrupt_log is set. 3) When redo log block checksum is wrong. In this case innodb code writes messages to error log with the following prefix: "Invalid log block checksum." The fix processes all the cases above.
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-09-2141-190/+454
| | |\ \ \ \ | | | |/ / /
| | | * | | MDEV-23741: Fix the resultMarko Mäkelä2020-09-211-1/+1
| | | | | |
| | | * | | Merge 10.2 into 10.3Marko Mäkelä2020-09-2139-199/+450
| | | |\ \ \ | | | | |/ /
| | | | * | MDEV-23751 : galera_3nodes test failures on ipv6 sst testsJan Lindström2020-09-184-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix assertion text it was too tight for some systems. This is backport from 10.4 and for Galera 3.
| | | | * | MDEV-23574 : galera_3nodes.galera_ipv6_mariabackup_section MTR failed: Could ↵Jan Lindström2020-09-1725-48/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not open '../galera/include/have_mariabackup.inc' Test case and configuration cleanup.
| | | | * | MDEV-21769 : `galera_3nodes.galera_safe_to_bootstrap` failsJan Lindström2020-09-173-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | Add wait_condition to wait correct cluster configuration.
| | | | * | MDEV-21655 : galera.galera_wan_restart_ist MTR fails sporadically: WSREP did ↵Jan Lindström2020-09-162-33/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not transition to state READY Replace sleeps with proper wait_conditions to wait correct cluster configuration.
| | | | * | MDEV-19264 Better support MariaDB GTID for Mariabackup's --slave-info optionVlad Lesin2020-09-142-0/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Parse SHOW SLAVE STATUS output for the "Using_Gtid" column. If the value is "No", then old log file and position is backed up, otherwise gtid_slave_pos is backed up.
| | | | * | MDEV-20396 Server crashes after DELETE with SEL NULL Foreign key and aNikita Malyavin2020-09-142-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtual column in index Problem: row_ins_foreign_fill_virtual was unconditionally set virtual fields to NULL even though the field is not a part of a foreign key (but a part of an index) Solution: The new virtual value should be computed with regard to cascade updates.
| | | | * | MDEV-23587 : galera_3nodes.galera_var_dirty_reads2 MTR failed: 1047: WSREP ↵Jan Lindström2020-09-112-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | has not yet prepared node for application use Add wait_condition tomake sure insert is replicated and server is after isolation back on ready state.
| | | | * | MDEV-18867 Long Time to Stop and StartThirunarayanan Balathandayuthapani2020-09-102-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fts_drop_orphaned_tables() takes long time to remove the orphaned FTS tables. In order to reduce the time, do the following: - Traverse fil_system.space_list and construct a set of table_id,index_id of all FTS_*.ibd tablespaces. - Traverse the sys_indexes table and ignore the entry from the above collection if it exist. - Existing elements in the collection can be considered as orphaned fts tables. construct the table name from (table_id,index_id) and invoke fts_drop_tables(). - Removed DICT_TF2_FTS_AUX_HEX_NAME flag usage from upgrade. - is_aux_table() in dict_table_t to check whether the given name is fts auxiliary table fts_space_set_t is a structure to store set of parent table id and index id - Remove unused FTS function in fts0fts.cc - Remove the fulltext index in row_format_redundant test case. Because it deals with the condition that SYS_TABLES does have corrupted entry and valid entry exist in SYS_INDEXES.
| | | | * | MDEV-23706 : Galera test failure on galera_autoinc_sst_mariabackupJan Lindström2020-09-092-99/+67
| | | | | | | | | | | | | | | | | | | | | | | | Remove infinite procedure and use direct INSERTs.
| | | * | | MDEV-23741 Windows : error when renaming file in ALTER TABLEVladislav Vaintroub2020-09-172-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The presumed reason for the error is that the file was opened by 3rd party antivirus or backup program, causing ERROR_SHARING_VIOLATION on rename. The fix, actually a workaround, is to retry MoveFileEx couple of times before finally giving up. We expect 3rd party programs not to hold file for extended time.
| | * | | | MDEV-23751 : galera_3nodes test failures on ipv6 sst testsJan Lindström2020-09-184-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | Fix assertion text it was too tight for some systems.
| | * | | | MDEV-23659 : Update Galera disabled.def fileJan Lindström2020-09-141-1/+0
| | | | | |
| | * | | | MDEV-20581 Fix MTR test wsrep.variablesJan Lindström2020-09-142-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Made the test work with --repeat option by adding galera_wait_ready.inc at the end of test. Recorded the test output.
| | * | | | MDEV-23617 : galera_sr.galera_sr_rollback_retry MTR failed: 1213: Deadlock ↵Jan Lindström2020-09-142-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | found when trying to get lock Add corrected wait_condition to wait until rows are in streaming replication log.
| | * | | | MDEV-23709 : Galera test failure on galera_fk_cascade_delete_debugJan Lindström2020-09-102-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add wait_condition so that inserts to parent and child are replicated and applied before we set debug sync point.
| | * | | | MDEV-23199 page_compression flag is missing for full_crc32 tablespaceThirunarayanan Balathandayuthapani2020-09-102-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ====== Making the tablespace as page_compressed doesn't do table rebuild. It does change only the FSP_SPACE_FLAGS. During recovery: 1) InnoDB encounters FILE_CREATE redo log and opens the tablespace with old FSP_SPACE_FLAGS value. 2) Only parsing of redo log has been finished. Now InnoDB tries to load the table. If the existing tablespace flags doesn't match with table flags then InnoDB should read page0. But in fsp_flags_try_adjust(), skips the page read for full_crc32 format. 3) After that, InnoDB tries to open the clustered index and it leads to failure of page validation. Fix: === While parsing the redo log record, track FSP_SPACE_FLAGS in recv_spaces for the respective space id. Assign the flags for the tablespace when it is loaded. recv_parse_set_size_and_flags(): Parse the redo log to set the tablespace recovery size and flags. fil_space_set_recv_size_and_flags(): Changed from fil_space_set_recv_size(). To set the recovery size and flags of the tablespace. Introduce flags variable in file_name_t to maintain the tablespace flag which we encountered during parsing of redo log. is_flags_full_crc32_equal(), is_flags_non_full_crc32_equal(): Rename the variable page_ssize and space_page_ssize with fcrc32_psize and non_fcrc32_psize.
| * | | | | MDEV-23650 Test S3 in buildbotElena Stepanova2020-09-203-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Temporarily disable failing S3 tests to allow the suite to run in buildbot: s3.partition and s3.partition_move are disabled due to MDEV-23648. While the problem is supposedly generic, the tests don't fail with Amazon setup, so they are disabled conditionally for emulator (MinIO). s3.replication_partition is disabled due to MDEV-23730, it fails both with Amazon and MinIO. s3.replication_mixed and s3.replication_stmt are disabled due to MDEV-23770, they also fail both with Amazon and the emulator.
| * | | | | MDEV-23767: IN-to-subquery conversion is not visible in optimizer tracebb-10.5-mdev23767Sergei Petrunia2020-09-202-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | Add the printout
| * | | | | Stabilize and clean up a testMarko Mäkelä2020-09-172-19/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The counter buffer_flush_background_total_pages may be unreliable, because pages can be flushed in different means. So, let us only check INNODB_BUFFER_POOL_PAGES_FLUSHED.
| * | | | | Make a test more robustMarko Mäkelä2020-09-172-56/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change buffering will occasionally happen if other pages are not flushed quickly enough.
| * | | | | MDEV-23591 : galera_3nodes.GCF-354 MTR failed: 1047: WSREP has not yet ↵Jan Lindström2020-09-142-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | prepared node for application use Stabilize test.
View Lorry Controller Status