PS-10059 Backport bug fixes from MySQL 8.0.41 #5652
Merged
Conversation
This file contains hidden or 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
PS-9442 Update the versions numbers
https://perconadev.atlassian.net/browse/PS-9603 Bug#34574604 mysql/mysql-server@632ca5cfe1b Background: When an online DDL is on-going and there are concurrent INSERTs, UPDATEs or DELETEs on the table, the changes in the rows are logged in the row log. After the DDL is complete, the row log is applied on the new table. If an error occurs when applying the row logs, the DDL reports the error and aborts. When applying the row log, if the base row contains any externally stored BLOB columns, then any UPDATE in the row log is applied as a DELETE followed by an INSERT. This is done first on the clustered index, then on all secondary indexes. The entries to be DELETEd and INSERTed are built from the row log entry. Any secondary index on virtual columns will need the virtual column information in the row log to build the correct entry, since the index entry contains the primary key value and the computed virtual column value. The row log entry writes the virtual column information only when the UPDATE changes the ordering field of the clustered index. An update not changing the ordering field will not write virtual columns to row log. This is irrespective of presence of secondary index on these columns. Issue: Applying the row log fails in the scenario illustrated by the test file. The failure occurs when the entry to be deleted in the secondary index is not found, as it is not built correctly. The table contains a BLOB column, a virtually generated column and a secondary index on the virtually generated column. The row being updated has the BLOB stored externally. The test performs an online DDL by adding a primary key, and concurrently updating the row such that the ordering of the new primary key does not change. Since the update does not change the ordering field, the row log does not contain the virtual column information. Since the row contains an externally stored BLOB, the row log's UPDATE entry is applied as a DELETE followed by an INSERT. The DELETE step fails when applied on the secondary index. The entry to be deleted from the secondary index is built incorrectly, as the virtual column value required is not present in the row log entry. Thus the incorrect entry built is not found in the secondary index, causing the DDL to abort. Fix: Log the virutal column information if the row contains externally stored BLOBs, either before or after the UPDATE. Change-Id: I90bac31cf293565467b3f0b19741c8c5d646f63f
…nobase_get_computed_value" This reverts commit 4bdd2da.
…et_computed_value https://perconadev.atlassian.net/browse/PS-9603 Bug#33691659 mysql/mysql-server@551288baa7a ANALYSIS ======== 1. A cascade delete from the parent table triggers delete on the child table. Before a clustered index record is deleted in the child table, a copy of row is built to remove secondary index record, since the secondary index is defined on the virtual column it is necessary to materialize the virtual columns. 2. We were skipping this materialization which causes it to fail on uninitialized template in innobase_get_computed_value() when trying to remove the secondary index rows defined on virtual column. FIX === 1. We must initialize virtual column template for materializing virtual column if child table has an index on a virtual column. Change-Id: Ib2381d81aa96024ed395261650421f6318f380b8
https://perconadev.atlassian.net/browse/PS-9603 Bug#37132323 mysql/mysql-server@dd8b0c5c7d6 The DB grant cache is not cleaned up at DROP USER. This was causing ghost grants until FLUSH PRIVILEGES. Fixed by flushing the cache. Change-Id: I1096558daffab2d5f75fe12af723680d5c1d2416
https://perconadev.atlassian.net/browse/PS-9603 Bug#36234681 mysql/mysql-server@a8c96ce81ab ANALYSIS DELETE operation on a table with self referential foreign key constraint and full text index may trigger an assert. When performing the DELETE operation, marking of deletion of the full text row happens twice due to the self referential foreign key constraint. Hence the state of the row becomes invalid and the assert is triggered. Fix Avoid updating the full text index if the foreign key has self referential constraint. Testcase added.
https://perconadev.atlassian.net/browse/PS-9603 Bug#36615714 mysql/mysql-server@6e08d4427fc Breaking the comment for a mysys option definition requires that no single word at the end of the comment (or every 57 chars if the comment is longer than 57 chars * 2) is longer than 57 chars. Fixed the logic to handle the lack of space. Change-Id: I2f48da5e0d066c208606058d095c7706dc12722c
https://perconadev.atlassian.net/browse/PS-9603 Bug#37063288 mysql/mysql-server@b76c48b031d Access to /proc/$pid/task/$thread_id/mem is required by stacktrace code. Change-Id: I6b6f8dd5c07ae5e867e0358fcbeccd5c5cd29bde
DASH IN HINT COMMENT https://perconadev.atlassian.net/browse/PS-9603 Bug#30875669 mysql/mysql-server@c510fe1470a mysql/mysql-server@ebdc6a2cd6c Problem: Server do not allow using '#' and '-- ' inside hint comment if preserve comments is turned off. Fix: Allow using '#' and '-- ' inside hint comment irrespective of preserve comments status because that is what is documented. Change-Id: I976f98e2954d9bc7f007b4acd6627726416b72ba
…NPLACE alter table https://perconadev.atlassian.net/browse/PS-9603 Bug#37189985 mysql/mysql-server@0fe52ea5c8f ANALYSIS ALTER TABLE, INPLACE operation on a table containing both a spatial index and an auto increment column can cause corruption. This is due to auto increment column value getting overwritten in the old records of spatial index while preparing the new record. The records are accessed through a cursor, cached into a tuple vector m_dtuple_vec in the index_tuple_info_t::add(). The row is built with shallow copying of fields, and the auto-increment value is prepared locally and copied. This process repeats until page traversal is complete. In subsequent iterations, shallow-copied pointers are overwritten, but since the source record remains intact and page is latched, they stay valid. The row continues to reference the old auto-incremented value, causing only the auto-increment field to be overwritten, and older rows to point to the latest auto-incremented value. FIX Perform deep copy of the auto-increment field while processing the spatial index records. Change-Id: Ib8852ef5977d881bf06dadcc35d41acfa760c96f
https://perconadev.atlassian.net/browse/PS-9603 Bug#33327093 mysql/mysql-server@0ac176453bf Analysis -------- 1. The parent table has 3 column of datatype (i) int (PK) (ii) varchar (iii) a virtual column which is generated by varchar column. 2. The child table has a column which is referring to the primary key of the parent table. 3. There is a update in the parent table which changes the primary key and the varchar column, so it tries to build the update node to propagate to the child table. 4. While building the update node it is trying to build the update field for virtual column which is causing the crash. FIX === 1. The virtual column update should not be present in the update node, because no column in child table can have a foreign key relationship with a virtual column. 2. So skip the update to the virtual column when building the update node for child table Change-Id: Iff7d1f32c7c9d846453c587fc0c5b8604ec679ec
…nt_arg https://perconadev.atlassian.net/browse/PS-9603 Bug#36593235 mysql/mysql-server@9a32e4495c5 Problem is seen when a subquery containing a aggregate function with rollup is part of a row value comparator and if there were no rows returned from the subquery. cmp_item_row::store_value() evaluates the subquery and goes ahead to store the values of the expressions in the comparator without checking if the result was assigned for the subquery. This leads to evaluation of a rollup expression when it is marked as not to be evaluated as aggregation was completed earlier. For the failing query, AggregateIterator() does evaluate the expressions. However HAVING clause does not qualify the rows. So the result of the aggregation is never cached. If a subquery returns empty result, bring_value() would set the "null_value" to true. cmp_item_row::store_value() now stores the value of the underlying comparator objects only when the result is not null. Else the result is set to null. Change-Id: I7bb17e621f1e5b439f6284c279ce69b80dace237
…ue to a bad comparator https://perconadev.atlassian.net/browse/PS-9603 Bug#37068527 mysql/mysql-server@04b8be52e59 Fixed the comparator to adhere to the C++ standard Change-Id: I78652a2e13dd814525b131e1ac9b5d9c68dca940 (cherry picked from commit e189888d621c735656a8239c91c980e5804be022)
…bit value https://perconadev.atlassian.net/browse/PS-9603 Bug#36879147 mysql/mysql-server@daa02f8852e Issue: FTS_DOC_ID is a 64-bit field and can have values 2^32 and higher. However current implementation only supports 32-bit value range. This limtation takes the form of: - Assertions - Use of unsigned long type which resolves to 32-bit on some platforms - VLC (variable length coding) implementation supporting up to 35 bits Fix: Support 64-bit doc IDs: - Remove assertions - Replace use of unsigned long for doc ID deltas with uint64_t - Extend VLC functions to support full unsigned 64-bit range Change-Id: Ifb56b33c5ec75e578391612eb371c41fc6aeef31
https://perconadev.atlassian.net/browse/PS-9603 Raised MYSQL_VERSION_EXTRA to 53 in MYSQL_VERSION file. Raised PERCONA_INNODB_VERSION to 53 in univ.i file.
PS-9603 Backport bug fixes from MySQL 8.0.41
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
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.
https://perconadev.atlassian.net/browse/PS-10059