PXC 4474 Merge PS 5.7.44-51 Q3 2024 #1943
Merged
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
Release-5.7.44-50
…E_INLINE' https://perconadev.atlassian.net/browse/PS-9301 Bug#36563773 mysql/mysql-server@2f67801d010 Limit the scale used when computing averages of decimal numbers. Simplified patch backported. Change-Id: If32143ad7ed55f841e3973e78fa8e98cc245e775
…s thread 1406284440 https://perconadev.atlassian.net/browse/PS-9301 Bug#34800754 mysql/mysql-server@c614f7c65b8 Issue: An assert in storage/innobase/include/dict0dict.ic triggers, indicating an invalid column index, while the column index is in fact correct. Background: The column index provided to dict_table_get_index_on_first_col is an index among all columns, while the n_cols field of dict_table_t only countains the number of non-virtual columns. Thus, the assert could be triggered with correct arguments. Fix: Changing the assert to compare against the n_t_cols field, the total number of columns. Change-Id: I90cc8c07d428c9117ca7873e9f53752d50f800e6
https://perconadev.atlassian.net/browse/PS-9301 BUG#36252805 mysql/mysql-server@fed401689c2 Problem: Checking if binlog cache is empty requires creating it first, then it will be empty. This causes sessions which never had or should not have binlog cache to get one, thus consuming unnecessary resources indefinitely. Analysis: It can be seen that binlog cache is created during for example rollback although the binlog cache does not exists and thus have no content. Several other places consider non existent binlog cache as empty. Solution: Change THD::is_binlog_cache_empty() to return true when binlog cache does not exist and remove calls to create the binlog cache before calling that function. Change-Id: I87e43dcff33a46790d0d29bc8259e38a1d1bd0ed
https://perconadev.atlassian.net/browse/PS-9301 Bug#36543458 mysql/mysql-server@76dd59535fb Bug#33142654 mysql/mysql-server@227ffcd4dad Same patch as for the original Bug#33142654 THE SECOND HEAP-USE-AFTER-FREE ISSUE OF MYSQL SERVER but for MacOS lower_case_table_name The fix is to test the QT_NO_TABLE flag before accessing table_name. Change-Id: I0b613f18663723e3e6a4c2b305641883000261ef (cherry picked from commit ec0e2c54bb1002ec350b505968873581e29b6b3f) (cherry picked from commit d86e0a201e0bcdf479d0afcd6fef1aa13135ae06) Bug #33142654 THE SECOND HEAP-USE-AFTER-FREE ISSUE OF MYSQL SERVER As part of optimizer trace in the range optimizer, we try to print a view definition, and this may access uninitialized data. This patch Bug#21929967 GCOLS: GCOL VALUE CHANGES WHEN SESSION CHANGES SQL_MODE introduced QT_NO_TABLE for printing identifiers. The fix is to test the QT_NO_TABLE flag before accessing table_name. Change-Id: I976cc2464e289851972c1151a122573f6f45f5ea
https://perconadev.atlassian.net/browse/PS-9301 mysql/mysql-server@132b094b046 Bug#35894664: Assertion in Bitmap<64>::is_set(uint) when forcing a spatial index scan. Bug#36361834: Incorrect result of getting data from a spatial index on column with SRID Bug#36366621: MySQL crash when explaining a force a spatial index containing column with SRID Bug#36361834: While setting up keys that could be used for covering index scans, a "geometry" keypart makes an index not covering. However, in case of innodb, a secondary index is always extended with primary key. While setting up the extended keypart spatial index is marked as covering. With force index in effect, spatial index is the only available index for optimizer to choose from. It picks "index-skip-scan" for the table. However, innodb does not support sequential scans on spatial indexes. This leads to wrong results with no rows retrieved. Bug#35894664 and Bug#36366621: When choosing covering index scans, optimizer picks the shortest covering key available. However, for the case where spatial index is the only available option, it fails to pick any index to do the index scan which leads to problems later. Solution to all these issues is that spatial indexes should not be marked as indexes that could be used for index only reads. There are a few inconsistencies in the code w.r.t this. So we try to correct them. While setting up keyparts, "geometry" field makes the index not covering but having an extended keypart which is not a geometry field makes the index covering which should not be the case. So we now disable spatial index for "index-only" reads irrespective of the extended keyparts. Change-Id: I44c04f79f35a270087a01c962f9ad35f5e3ad534
…DISCOVERABLE https://perconadev.atlassian.net/browse/PS-9301 Bug#29539976 mysql/mysql-server@131035749d9 Before this fix: After loading the connection_control plugin, the performance schema instrumentation embedded in the code was not visible in table performance_schema.setup_instrument. This is a problem because available instruments are harder to discover: the workload has to execute a specific code path for the instrument to be eventually added in the performance schema. In this case, a connection had to actually be blocked by the connection control plugin for the mutex and cond to appear. This problem in particular affects the LOCK_ORDER tool, which failed to find the instrumentation in the connection control plugin. Root cause: PSI_server->register_mutex() was not called on plugin init but later during the plugin execution. Fix: The performance schema instrumentation for the connection_control plugin was reviewed in details, leading to the discovery and fix for the following issues: 1) Mutexes, rwlocks and conditions were not registered up front on plugin init, but later. For mutexes and conds, the registration was executed multiple times, which is un necessary. For rwlocks, the registration was correct (done once and always), but the code pattern was inconsistent with instrumentation in general. All items are now registered once at plugin init. 2) A stage was defined, but never registered, so that the performance schema was just ignoring it, treating the stage as un instrumented. The stage is now instrumented properly.
https://perconadev.atlassian.net/browse/PS-9301 Bug#35205358 mysql/mysql-server@3fc9c6a63a2 Problem: Stage "conn_delay/Waiting in connection_control plugin" was not reset after delay introduced by connection control plugin which lead to incorrect monitoring intormation. Fix: Set the stage to the original one after the delay. Test: Check if the connection delay status last expected amount of time according to the performance schema. Change-Id: I810398a274fedb91b545c60875860a24ac953609
https://perconadev.atlassian.net/browse/PS-9301 Bug#33057164 mysql/mysql-server@987fc9a5ea6 Bug#33057164 mysql/mysql-server@d4e67f67356 Problem: When executing a PREPARED statement, table performance_schema.threads does not populate the PROCESSLIST_INFO column. This prevents to properly observe the execution of prepared statements. This is also a regression, introduced in: - MySQL 5.6.46 - MySQL 5.7.28 - MySQL 8.0.18 Root cause: The fix for: Bug 20712046 SHOW PROCESSLIST AND PERFORMANCE_SCHEMA TABLES DO NOT MASK PASSWORD FROM QUERY removed a call to PSI_THREAD_CALL(set_thread_info) located in THD::set_query() PSI_THREAD_CALL(set_thread_info) was called from different places in the same fix, to make sure a properly sanitized query text is displayed if needed, but the code path for prepared statements was overlooked. Fix: The fix is to call PSI_THREAD_CALL(set_thread_info) in the missing code path, when executing a prepared statement. The call uses either the executed query, or a sanitized version of it if it contains sensitive data. Additional fix: The logic around rewrite_query_if_needed() was revised. Trying to anticipate if a query will be displayed or not, to possibly save a rewrite, is too fragile, and too dangerous. Queries that contain sensitive data are always rewritten, regardless of whether the query will actually be printed somewhere or not. Change-Id: Ief9c80a24f539f0889371766843d2f7b05812ad8
This reverts commit d60853b.
…ltext_only https://perconadev.atlassian.net/browse/PS-9301 Bug#34929814 mysql/mysql-server@66cc7556964 Symptom: When running OPTIMIZE TABLE on a table with FTS index with innodb_optimize_fulltext_only option enabled, the last word to be processed is very rarely and apparently randomly processed twice. Root cause: When zlib uncompressed the end of a compressed stream, inflate() will either return Z_STREAM_END, or it will return Z_OK, in which case the subsequent call will output 0 bytes and return Z_STREAM_END. fts_zip_read_word function handles the first case correctly, but in the second the behavior is incorrect: on the call, where Z_STREAM_END is returned from inflate(), fts_zip_read_word returns true without actually touching the word buffer. When this happens, the caller interprets this as the function having read the same word as it read on the previous call, and processes that word again. Fix: Change the logic of the function to return false if inflate() returns Z_STREAM_END without reading any bytes. refactor to make explicit the various states when reading a word from the compressed stream. Change-Id: Ib777a03b5dac0fc8bda2022b0342177f1c7d2e4a
https://perconadev.atlassian.net/browse/PS-9301 Raised MYSQL_VERSION_EXTRA to 51 in MYSQL_VERSION file. Raised PERCONA_INNODB_VERSION to 51 in univ.i file.
PS-9301 Backport bug fixes from MySQL 8.0.38
RM-1419 PS-5.7.44-51 (post-EOL 3)
https://perconadev.atlassian.net/browse/PXC-4474 Merge tag 'Percona-Server-5.7.44-51' into PXC-4474 Percona Server release 5.7.44-51 *** Changes in the `build-ps` directories were ignored and the PXC version of them were restored. *** Conflicts: MYSQL_VERSION build-ps/percona-server-5.7_builder.sh sql/binlog.cc
https://perconadev.atlassian.net/browse/PXC-4474 * Resolved conflicts in MYSQL_VERSION. * Resolved conflicts in sql/binlog.cc.
|
Jenkins : https://pxc.cd.percona.com/job/pxc-5.7-param/457/ |
|
Created https://perconadev.atlassian.net/browse/PXC-4487 to keep track of galera_kill_connection failure. |
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/PXC-4474
Merge tag 'Percona-Server-5.7.44-51' into PXC-4474
Percona Server release 5.7.44-51
Changes in the
build-psdirectories were ignored and the PXC versionof them were restored.
Conflicts:
MYSQL_VERSION
build-ps/percona-server-5.7_builder.sh
sql/binlog.cc
Resolved merge conflicts