Null merge PS 5.7.44-50 at https://github.com/percona/percona-server/commit/899a9b79e71 into 8.0 #5376
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://perconadev.atlassian.net/browse/PS-9067 Post-push fix. Masking of variable paths now considers the case when MTR tests are run parallely with multiple threads.
https://perconadev.atlassian.net/browse/PS-9174 Bug#36248967: mysql/mysql-server@f351ea92a5a mysql/mysql-server@c334b7e5f02 Problem: mysqldump not sanitizing the version string obtained from server which may lead to injecting malicious commands to the output. Fix: added function sanitizing the version string by cutting off illegal part and issuing warning. Test: check the server version in the output with and without injected payload. Change-Id: I1f19e1c90bdb8d444285e427092face3bb16da01
https://perconadev.atlassian.net/browse/PS-9174 Bug#35846221 mysql/mysql-server@3cd7cd2066f Problem is due to missing implementation of Item_func_make_set::fix_after_pullout(), which makes this particular MAKE_SET function be regarded as const and may thus be evaluated during resolving. Fixed by implementing a proper fix_after_pullout() function. Change-Id: I7094869588ce4133c4a925e1a237a37866a5bb3c (cherry picked from commit a9f0b388adeef837811fdba2bce2e4ba5b06863b)
https://perconadev.atlassian.net/browse/PS-9174 Bug#35904044 mysql/mysql-server@271dcf231d0 There may be a failure when returning metadata to the client for certain SQL queries involving dynamic parameters and subqueries in a SELECT clause. The fix is to avoid setting an item name that is a NULL pointer. Change-Id: I1abe206f97060c218de1ae23c63a4da80ffaaae5
https://perconadev.atlassian.net/browse/PS-9174 Bug#35854362 mysql/mysql-server@c7e824d18f7 Description: - Indexes are ordered based on their keys. Loose index scan effectively jumps from one unique value (or set of values) to the next based on the index’s prefix keys. - To “jump” values in an index, we use the handler call: ha_index_read_map(). - the first range read sets an end-of-range value to indicate the end of the first range. - The next range read does not clear the previous end-of-range value and applies it to the current range. - Since the end-of-range value has already been crossed in the previous range read, this causes the reads to stop. So the iteration is finished with the current range without moving onto the next range(unique set of values)resulting in an incorrect query result. Fix: - In order to find the next unique value, the old end-of-range value is cleared. Change-Id: I84290fb794db13ec6f0795dd14a92cf85b9dad09
https://perconadev.atlassian.net/browse/PS-9174 BUG#36093405 mysql/mysql-server@6467f70f615 Group Replication maintains a memory structure that keeps track of transactions accepted to commit but not committed on all members yet. This structure, named certification info, is used to detect conflicts and dependencies between transactions. The certification info is cleaned periodically and on Group Replication stop. There was a race identified between these two operations, more precisely: 1) Certifier::garbage_collect() -> while (it != certification_info.end()) { if (it->second->is_subset_not_equals(stable_gtid_set)) { if (it->second->unlink() == 0) delete it->second; 2) Certifier::~Certifier() -> clear_certification_info(); -> for (Certification_info::iterator it = certification_info.begin(); it != certification_info.end(); ++it) { if (it->second->unlink() == 0) delete it->second; `clear_certification_info()` was being called without securing exclusive access to `certification_info` which could cause concurrent access to its items, more precisely `delete it->second`. To solve the above issue, `~Certifier()` (like all other callers) do secure the exclusive access to certification info. Change-Id: I28111d41adb54248d90137ee9d2c17196de045e8
https://perconadev.atlassian.net/browse/PS-9174 Bug#35277407 mysql/mysql-server@88b0ebafdf6 This patch will solve the following duplicates of this bug: Bug #112425: trx_t might be Use-After-Free in innobase_commit_by_xid Bug #99643: innobase_commit_by_xid/innobase_rollback_by_xid is not thread safe Bug #105036: trx would be used after free in `innobase_commit_by_xid` and rollback Background: TrxInInnoDB is a RAII wrapper for trx_t object used to track if the transaction's thread is currently executing within InnoDB code. It is acquired on all entry points, and as Innodb can be entered "recursively", the trx->in_depth is used to track the balance of enters and exits. On the outermost enter, the thread additionally checks if trx->in_innodb has the TRX_FORCE_ROLLBACK (0x8000 0000) flag set, which means a high priority transaction is attempting an asynchronous rollback of this transaction, so to avoid races, this thread should wait for the rollback to complete. Issue: TrxInInnoDB's destructor calls exit which resets in_depth and in_innodb increased by enter. However innobase_commit_by_xid and innobase_rollback_by_xid calls trx_free_for_background which returns the trx back to the pool, before the destructor is called. If this trx is being reused by another thread, it can lead to data-race and corrupted value of in_depth and in_innodb. If in_depth gets the value of -1, subsequent calls to enter and exit will bump in_innodb by one. This can lead to indefinite wait if in_innodb reaches TRX_FORCE_ROLLBACK. Fix: Ensure that TrxInInnoDB calls exit before returning the trx object to the pool. Further add checks to catch corrupt values of in_depth when freeing trx. Trx state validation before free was missed in trx_free_prepared_or_active_recovered Thanks to Shaohua Wang (Alibaba, Ex-Innodb) for the contribution Change-Id: Ibf79bec85ffa0eaf65f565c169db61536bff10a2
https://perconadev.atlassian.net/browse/PS-9174 Bug#34929814 mysql/mysql-server@c94f9d873b1 mysql/mysql-server@a0367984115 Bug#36347647 Contribution by Tencent: Resiliency issue in fts_sync_commit Symptoms: During various operations on tables containing FTS indexes the state of FTS as comitted to database may become inconsistent, affecting the following scenarios: - the server terminates when synchronizing the FTS cache, - synchronization of FTS cache occurs concurrently with another FTS operation This inconsistency may lead to various negative effects including incorrect query results. An example operation which forces the synchronization of FTS cach is OPTIMIZE TABLE with innodb_optimize_fulltext_only set to ON. Root Cause: Function 'fts_cmp_set_sync_doc_id' and 'fts_sql_commit' use different trx_t objects in function 'fts_sync_commit'. This causes a scenario where 'synced_doc_id' in the config table is already committed, but remaining FTS data isn't yet, leading to issues in the scenarios described above - the server terminating between the commits, or concurrent access getting the intermediate state. Fix: When 'fts_cmp_set_sync_doc_id' is called from 'fts_sync_commit' it will use the transaction provided by the caller. Patch based on contribution by Tencent. Change-Id: I65fa5702db5e7b6b2004a7311a6b0aa97449034f
https://perconadev.atlassian.net/browse/PS-9174 Bug#36317795 mysql/mysql-server@ce036717cb5 This patch unifies plugin's deinit function call to pass valid plugin pointer instead of the nullptr for all types of plugin. Change-Id: I482497bbaff28d5cd31d74d694056a4df6693152
https://perconadev.atlassian.net/browse/PS-9092 Problem: Query over InnoDB table that uses backward scan over the index occasionally might return incorrect/incomplete results when changes to table (for example, DELETEs in other or even the same connection followed by asynchronous purge) cause concurrent B-tree page merges. Cause: The problem occurs when persistent cursor which is used to scan over index in backwards direction stops on infimum record of the page to which it points currently and releases all latches it has, before moving to the previous page. At this point merge from the previous page to cursor's current one can happen (because cursor doesn't hold latch on current or previous page). During this merge records from the previous page are moved over infimum record and placed before any old user records in the current page. When later our persistent cursor resumes its iteration it might use optimistic approach to cursor restoration which won't detect this kind of page update and resumes the iteration right from infimum record, effectively skipping the moved records. Solution: This patch solves the problem by forcing persisted cursor to use pessimistic approach to cursor restoration in such cases. With this approach cursor restoration is performed by looking up and continuing from user record which preceded infimum record when cursor stopped iteration and released the latches. Indeed, in this case records which were moved during the merge will be visited by cursor as they precede this old-post-infimum record in the page. This forcing of pessimistic restore is achieved by increasing page's modify_clock version counter for the page merged into, when merge happens from the previous page (normally this version counter is only incremented when we delete records from the page or the whole page). Theoretically, this might be also done when we are merging into page the page which follows it. But it is not clear if it is really required, as forward scan over the index is not affected by this problem. In forward scan case different approach to latching is used when we switch between B-tree leaf pages - we always acquire latch on the next page before releasing latch on the current one. As result concurrent merges from the next page to the current one are blocked. Note that the same approach to latching can't be used for backward iteration as it will mean that latching happens into opposite order which will lead to deadlocks.
…h in Gtid_state::save https://perconadev.atlassian.net/browse/PS-9132 When the server is killed before persisting the GTIDs into mysql.gtid_executed, the subsequent crash recovery process fails to recover gtids from the binary logs because it does not find the "Prev_gtid_log_event" in the last binary log. This happens because, the last binlog was created during the previous restart but no information about Prev_gtid_log_event was written into the file since the server was killed before persisting to the table. The root cause here, is that the recovery process does not parse the previous binary logs if "Prev_gtid_log_event" was not found in the last binary log created by the server. This issue is fixed by parsing all previous binary logs until a valid "Prev_gtid_log_event" is seen. The test case, encrypted_master_unload_keyring is adjusted for additional warnings.
…833:ib::fatal https://perconadev.atlassian.net/browse/PS-9174 Bug#36343647 mysql/mysql-server@5d06230ae2a This is a cherry-pick of the following bug fix which is already fixed in 8.4 through commit#79d67. Bug#35676106 Assertion failure: ibuf0ibuf.cc:3825:ib::fatal triggered thread Description: ------------ When the pages of secondary index are brought to the buffer pool either through the ibuf merge background thread or read through usual io thread, first cached entries from the change buffer are applied to the pages. Once the entries are applied to the page, they are removed from the change buffer. It may possible that the table is deleted or being deleted during change buffer related operations described in the earlier. In the current code we handled the situation of tablespace is deleted but not being deleted. Latter situation must also be handled similarly. Fix: ==== - Replaced the call fil_space_get_flags() with fil_space_acquire_silent(). Later method refuses to acquire the tablespace that is being deleted. - Improved the doxygen of the method ibuf_restore_pos() Change-Id: Ibc5a07c705988282b8b7906d645e2a108f4ada76
https://perconadev.atlassian.net/browse/PS-9174 Raised MYSQL_VERSION_EXTRA to 50 in MYSQL_VERSION file. Raised PERCONA_INNODB_VERSION to 50 in univ.i file.
PS-9174 Backport bug fixes from MySQL 8.0.37
Release-5.7.44-50
Release-5.7.44-50
…e-mysql-5.7.44-50
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.