PXC-4593: [Dev] Code refresh for - PXC 8.0.41 #2051
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
…-fix] Missed check on test to only run on debug builds. Change-Id: I2aa1c5bed5ad2bf642d77792804ea82b4a75aefd
Change-Id: I3651390d62e8667c42a41e1ceea651852d2a05e1
Change-Id: Ib64c017dc603bce0a04eb26b2d8aa27ac67097ef
DASH IN HINT COMMENT [post-push fix] Test fails on --embedded with error: sh: select#1: command not found Hence disabling on --embedded Approved by: Miroslav Rajcic <[email protected]>
Change-Id: I40ab28569c2f40d5f3908832c65edf4e265785e5
Every object in fts_cache_t::get_docs vector should have its cache field set to point to the containing fts_cache_t object. When fts_reset_get_doc re-sets the get_docs vector, it does not set the field. Fix: Set fts_get_doc_t::cache in fts_reset_get_doc. Change-Id: I1947462a07ba53ce0e8d5155f220f2a78825e919
Remove text that wasn't supposed to be there in the first place. Change-Id: I5bd4771f25fefdd4581d8636854e0930eabe345f (cherry picked from commit 0d1164e80cf5d72fbcff4af7500197d5f08d988e) (cherry picked from commit ce527f4cd6a573ddfe1ac054b875aee8806c0356)
Define RAPIDJSON_HAS_STDSTRING=1 for the rapidjson interface target. Remove explicit definitions before including rapidjson headers. Change-Id: I60aa0ea60e246d4f3638e5c05dec92602f1f74c4 (cherry picked from commit 9ad50ced4d2fdb6a8f5ebb3e28bf8b3ef0994824)
…=1091, page number=0] of Symptom: Test script fails sporadically with the error that table space for the table is not found. Cause: Test case is to test the working for dblwr buffer. It 1 Stops the checkpointer 2 Inserts some rows in table (causing changes in pages in the tablespace) 3 These changes are REDO logged. 4 Kill the server 5 corrupt the pages manually 6 Restart the server. REDOs are applied (can't be truncated as checkpointer is stopped). 7 Read pages are corrupted, so dblwr copy is used. To make the test work, the REDOS generated in step 3, MUST be flushed to disk. If they are not (the failure case) during REDO recovery, the corresponding pages are not read. So InnoDB doesn't know that the pages are corrupted. And later when they are read and found corrupted, we don't have dblwr copy of page. So InnoDB doesn't load the tablespace and error out that tablespace is not found. Fix: Make sure the REDOs generated in step 3 are flushed to disk Change-Id: I406d93ef4b9cadffbeeae298bf5ed22b913c47e7
…cover Symptom: Test script fails sporadically with the error that table space for the table is not found. Cause: Test case is to test the working for dblwr buffer. It 1 Stops the checkpointer 2 Inserts some rows in table (causing changes in pages in the tablespace) 3 These changes are REDO logged. 4 Kill the server 5 corrupt the pages manually 6 Restart the server. REDOs are applied (can't be truncated as checkpointer is stopped). 7 Read pages are corrupted, so dblwr copy is used. To make the test work, the REDOS generated in step 3, MUST be flushed to disk. If they are not (the failure case) during REDO recovery, corresponding pages are not read. So innodb doesn't know that the pages are corrupted. And later when the pages are read, they are found corrupted and InnoDB error out saying page can't be read. Fix: Make sure the REDOs generated in step 3 are flushed to disk Change-Id: I9021db62b01e0be56b921a99d5a4bf185fff7956
… errors
Add testcases to testScan showing problems with Api and Kernel
error interactions in scans.
testScan -n ScanErrorCleanup T1
Shows case where API error tramples kernel side error resulting
in 'nocloseneeded' behaviour for scan, reuse and then TC state
crash
testScan -n ScanErrorHandling T1
More comprehensive testcase covering combinatorial space of
scan error sources :
- Type : Table, Range, Range-ordered
- Locking : Y/N
- Delay before iteration (racing incoming signals or not)
- When error occurs : Pre-exec, Pre-iterate, During-iterate, After
- What error occurs : None, Early scan reject, Late scan fail, Api error
Test checks :
- (No crashes / no overall test timeout)
- Number of API side Transaction objects does not increase
- Subsequent transactions do not crash (kernel side object state ok)
Change-Id: I47a0733940c94f8e82c600b0242755b1cea68d31
Bug#37022773 (2/2) Separate handling of NdbApi kernel and Api sourced errors
Scan objects allow API interaction concurrently with the reception of
incoming signals related to the scan.
Incoming signals use the scan object's error code to manage scan
protocol error handling and subsequent closure.
Problem
This is flawed as the API may set a scan object's error code so that
subsequent closure does not operate correctly.
This can lead to :
- Scan protocol timeout waiting for signals that the kernel will
not send
- Failure to close the scan resources on the kernel, leading to
data node side state assertions.
Solution
The signal handling part of the code assumes that any error which
is set has been set by e.g. SCAN_TABREF handling.
Make this true by maintaining separate 'kernel error' and
'API/overall error' objects.
Signal handling sets only the kernel error object.
Signal handling based on the error examines only the kernel error
object
When the user makes a blocking call into the API (nextResult/close),
if the kernel error object is set, then it is copied to the API error
object so that the user becomes aware.
Refactoring
When implementing the fix, it can be seen that an analogous design is
used for SPJ, with the implementation encapsulated rather than implemented
in NdbTransactionScan.
This model is used to extend the 'execCLOSE_SCAN_REP()' method in a symmetric
way, which encapsulates the scan object's handling of errors and completions.
Change-Id: I8b2bc6471e6b4b826a543b51056dac755e25fcb6
…handling
Add transactions_full base table to ndbinfo
The existing cluster_transactions table is filtered at source
in TC to exclude ApiConnectRecords which are seized, but not
in use.
This is likely aligned with the user's expectations, but makes
some resource usage unobservable.
A new base table is added without this filtering, as a
parameterised variant of the existing table.
No user-visible view is added at this time.
Change-Id: I23cff8a6ac0f719e82c843d465504929d7bc733a
Bug#37022901 (2/7) Improve NdbApi Table and OI scan protocol timeout handling
Add reduced timeout DBUG capability to NdbAPI.
New DBUG variable allows tests to be run to show timeout behaviour
without needing to wait 6 minutes for every iteration.
Modify direct access to the value from check_send_timeout() to ensure
that it is affected when the API timeout is reduced.
Change-Id: I7af78a6c70845323ee5e13af0e5b3a8f80791b02
Bug#37022901 (3/7) Improve NdbApi Table and OI scan protocol timeout handling
Add error inserts for testing timeouts
5112 (LQH) : Range scans get an infinite sequence of MRR ranges so that
they never terminate.
With a non-matching pushed filter, they will scan indefinitely
with no results
8124 (TC) : SCAN_FRAGCONF signals stall indefinitely, causing scans to
timeout, and close() requests are unable to resolve until
error insertion is cleared
Change-Id: Id7f7f29d2eab5a87e30cef40a02817d4355d5fda
Bug#37022901 (4/7) Improve NdbApi Table and OI scan protocol timeout handling
New MTR testcase ndb_scan_protocol_timeout
New testcase added which tests system behaviour of :
- Unordered + Ordered scans
- 'Load' and 'Bug' timeout scenarios (via error inserts)
Test checks :
- TC resource usage to ensure no 'leaks' of ApiConnectRecords
- Ability to query after all tests are complete
New include file ndb_get_api_connect_count uses new
ndbinfo.ndb$transactions_full base table to observe seized but
inactice (CS_CONNECTED) ApiConnectRecords.
No result file recorded as test fails without subsequent patches.
Change-Id: I42f920e98117f6f67a3122a2879047e8535a5738
Bug#37022901 (5/7) Improve NdbApi Table and OI scan protocol timeout handling
Remove error code 4008 handling from closeTransaction()
Scan operation variants may set error 4008 on both a 'scan' and 'main'
transaction object when a scan times out.
When that main transaction is closed in closeTransaction(), the presence
of error 4008 causes it not to be closed, but rather 'forgotten'.
This results in both the main transaction object + ApiConnectRecord, and
any related scan transaction objects + their ApiconnectRecords, to be
leaked.
This occurs whether or not the scan encountering 4008 has subsequently
been closed correctly at the kernel.
The leak is detected via assertion failures in debug builds
(as NdbList detects that some allocated resource has not been returned).
As part of fixing timeout behaviour this special error code based
behaviour is removed.
If there is some situation where the kernel side of a scan cannot be
closed then the kernel side object may be leaked (until API disconnection),
but the api side object is not.
The baseline ndb_scan_protocol_timeout test result is recorded here,
showing 4 situations, each resulting in 1 ApiConnectRecord object being
leaked at TC.
Change-Id: I1ead0a95ebfdb2ab03276df437aa4a6cc0963bd7
Bug#37022901 (6/7) Improve NdbApi Table and OI scan protocol timeout handling
Protocol timeouts mark scans as needing close at kernel
The current timeout handling results in an error being set on the object,
but not in a way that ensures that an attempt will be made to cleanup
the kernel-side of the scan when close() is called.
The behaviour then depends on whether there were any 'confirmed' receivers
at the time the error was received (unlikely).
This is changed to handle an api protocol timeout in a similar way
to receiving a SCAN_TABREF from the kernel with an error code and
the 'need_close' flag set.
The code invoked in this case is reused.
This should result in a clean close of the scan in cases where the
scan is timing out due to 'LOAD' (e.g. the scan is busy but has returned
no results for 6 minutes).
In 'BUG' cases it will result in an attempt to close the scan (which may
help, depending on the problem).
The testcase result is updated to show that the 'LOAD' cases now have no
ApiConnectRecord leak for ordered scans.
Unordered scans continue to leak as they have a further bug
Future ideas :
- Allow users to control timeout duration
- Allow users to set a non-error timeout (polling)
- Have kernel send a scan HB to reset api protocol timeout
Change-Id: I92aad65f6214505cd6abd5f3e97997ac20084c9f
Bug#37022901 (7/7) Improve NdbApi Table and OI scan protocol timeout handling
Only set ReleaseOnClose if close() times out
An NdbTransaction's ReleaseOnClose member is used to indicate that the
TC ApiConnectRecord associated with the NdbTransaction is 'gone', and so
when the transaction is next closed, the API side NdbTransaction object
should return to an anonymous free pool, ready to be associated with a
different ApiConnectRecord object.
The primary use case for this is when a data node fails - all the
ApiConnectRecords it had are now gone / unreachable, so the API must
detach its NdbTransaction objects from those.
Cases where current scan code is setting this member to true :
- executeCursor()
Node fail detected when sending : OK
- In unordered scan nextResult() for 3 cases
scan timeout (-1) : Maybe
node failure (-2) : OK
node seq change / signal send failure (-3) : Maybe
- In close_impl()
When node seq is changed : OK
Wait-for-outstanding
timeout (-1) : Maybe
node failure (-2) : OK
Send-close
signal send failure : OK
timeout (-1) : OK
node-failure (-2) : OK
The ordered scan nextResult() code is not setting this member to true
as it assumes that in cases where the node fails, the sequence
number will change and this will be detected in close_impl()
This explains the test result difference between the ordered and
unordered scan cases.
If there is a timeout in nextResult() in an unordered scan the
nextResult() code sets theReleaseOnClose flag even in cases where
close_impl() manages to close the scan, resulting in an ApiConnectRecord
leak.
This patch aligns the unordered nextResult() code with the ordered
nextResult() code :
- There is no explicit setting of theReleaseOnClose flag
for timeout *or* node failure
- The change in node sequence number is relied on to detect
the node failure case
- Extra logging is added so that if there is a timeout case,
it is logged as either :
- Timeout occurred and was successfully handled in close()
- Timeout occurred, and close failed to handle.
The ndb_scan_protocol_timeout testcase result is updated to show
the removal of the unordered scan 'LOAD' scenario ApiConnectRecord
leaks with this patch.
Change-Id: I289d69f8a6bb8728c071d959dde74c7b2c0cfbf0
This test should not have been pushed to the mysql-8.0 branch; it should exist only in versions 8.4 and up. Change-Id: I612b0bf76defdd2dfc4b9e2753a476b33f949a8f
Garbage collector number of runs when initialized to same value of write set counter will delay the removal of values from certification garbage collect. This only impact scenarios of test but the solution is simple, initialize to garbage collect runs to one more. Change-Id: Ib47b5634fe84c462b5008bd5c210abd3cf88aab1
…=1091, page number=0] of Post-push fix Error message in error log to be ignored is not being ignored on WINDOWS Change-Id: I593abb528c8b7a3b45cd0732888aa28672c10d5e
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
Patch 1: git add the original tarball. https://thrysoee.dk/editline/libedit-20240808-3.1.tar.gz Remove before checkin: config.guess config.sub, m4/* Change-Id: I88375b9959e846a87fa62c9147710bb34492af2b (cherry picked from commit 5b83fbb4cb38eba0448f22e1d9bc060948f273fa)
Patch 2: Add cmake code based on the .ac and .am autotools files. No relevant changes to .ac and .am files. Copy from old libedit directory: src/CMakeLists.txt src/config.h and add the new files. Rename src/makelist to src/makelist.in so we can subst @awk@ in it. Change path to current libedit in cmake/readline.cmake. Change-Id: I700c63d2c0a957afd35562a2c594529b85d43e62 (cherry picked from commit ae16e9ab60e161cffe3ee750d9b2fbc259d2bfa7)
Patch 3: Local patches - parse.c : fix maybe-uninitialized warnings - read.c : handle SIGINT i.e. control-c - sys.h : Get SIZE_MAX from the standard header <limits.h> Change-Id: Ia923fda20d9d567e8efa063e1cf3d3529b49253f (cherry picked from commit 685f25fde6fe817eb572cf90ed7c00b7761eaa2d)
Patch 4: git rm -r libedit-20221030-3.1 Change-Id: Ibdf9765c7e7e384b6f71f58488f1e03fba4512d4 (cherry picked from commit 212401300f750fb8c2db8bbef47db0180ae7f54e)
Downgrade a few compiler warnings for LTO builds. Change-Id: I057fe0e4a4de936b48a6ccb675c2da7001f90439 (cherry picked from commit 5f3f6ebe94183277b9aa1a683552764db0de9460) (cherry picked from commit 120595d985930d8730b7622e07d4e1c6e9f40557)
…m tablespace Following two observations are reported in this bug. 1. Change buffer is a B-Tree that is persisted in the System tablespace. If innodb_file_per_table is turned OFF then tables are created in the system tablespace. Any of the above two may cause Innodb to extend the system tablespace but InnoDB stopped producing the MLOG_FILE_EXTEND log record type for the system tablespaces through WL#13782/RB#23888. The rationale of doing this change was clarified in the code comments but it doesn't justify of doing this change. We can easily see the system tablespace extending second case when innodb_file_per_table is turned off. 2. Right after extending the space size we were not updating the space and node(s) size variables under the shard mutex. This may cause IO thread(s) believing that space size and accumulated nodes size differ when it calls Fil_shard::validate() method. Fix ==== 1. Removed the artificial restriction of not producing the MLOG_FILE_EXTEND log record for the system tablespace as well. Also the tablespace scanning system doesn't track the system tablespace. Therefore, added a check to skip looking for system tablespace in fil_tablespace_redo_extend method. 2. Update the node and space size together under the shard mutex. Since we had shard handle so replaced the fil_flush() call with space_flush() that doesn't make any difference. Added a test case to demonstrate that system tablespace extends when the change buffer grows. Change-Id: Icf53861c434565b98a22e949045393f98f9d27a9
… failing rarely Symptom: Debug build o mysqld occasionally fails on assertio in ddl::Key_sort_buffer::serialize (ddl0buffer.cc): ut_ad(ptr > io_buffer.first); Cause: The code around this assertio supports the case where data left in the buffer after serializing the records would overrun the buffer if aligned to IO_BLOCK_SIZE. In this case all complete blocks of data are persisted to make room in the buffer for the final block. The scenario occurs when the length of that left over data is a multiple of IO_BLOCK_SIZE; in this case all of it is persisted, and nothing is left. The assertion does not anticipate that situation, although the code supports it correctly. Fix: Assertion is changed to allow for this scenario - after persisting the data the buffer may be empty, and "past the end" pointer will be equal to the start of the buffer. Change-Id: Icbaef197123f0fc85dbdba7c0259e3dcc9352920
Problem Testcase was added as part of fix for Bug#22602898 NDB : CURIOUS STATE OF TC COMMIT_SENT / COMPLETE_SENT TIMEOUT HANDLING That fix modified TC timeout handling to avoid the 'switch to serial' behaviour when detecting a timeout, as it can result in excessive slowdown for large transaction commits, leading to long + large epochs, replication problems etc. Test testNodeRestart -n TransStallTimeout tested this fix by stalling a transaction in the commit or complete phase and checking that it was *not* unblocked (and committed) by TC timeout switching to the serial commit protocol. However there was an issue with transient transaction states which were not directly handled as part of node failure, and so relied on the non node-failure timeout handling to cleanup. This was detected and fixed in : Bug#36028828 testNodeRestart -n MixedReadUpdateScan failures That fix uses the difference between the TC's global 'failure number' counter and an ApiConnectRecord's local failure number to detect when a node failure has occurred since a transaction started, to detect and cleanup transactions which were in transient states when the node failure was detected. However it is observed that testNodeRestart -n TransStallTimeout fails occasionally in the COMPLETE phase - a transaction blocked in the COMPLETE phase is unblocked by normal COMPLETE timeout handling. Investigation shows that the problem is that in some cases the ApiConnectRecord's failure number is not initialised. This is because the COMPLETE phase uses a different ApiConnectRecord (Copy record) than the PREPARE + COMMIT phases, to allow the PREPARE + COMMIT record to be used for a new transaction concurrently with COMPLETE. Solution Ensure that the Copy ApiConnectRecord has an initialised Failure number. Change-Id: I725d80bb3230eeeeb3c3e357943738dfdfc3f434
Backport to 7.6 Problem Testcase was added as part of fix for Bug#22602898 NDB : CURIOUS STATE OF TC COMMIT_SENT / COMPLETE_SENT TIMEOUT HANDLING That fix modified TC timeout handling to avoid the 'switch to serial' behaviour when detecting a timeout, as it can result in excessive slowdown for large transaction commits, leading to long + large epochs, replication problems etc. Test testNodeRestart -n TransStallTimeout tested this fix by stalling a transaction in the commit or complete phase and checking that it was *not* unblocked (and committed) by TC timeout switching to the serial commit protocol. However there was an issue with transient transaction states which were not directly handled as part of node failure, and so relied on the non node-failure timeout handling to cleanup. This was detected and fixed in : Bug#36028828 testNodeRestart -n MixedReadUpdateScan failures That fix uses the difference between the TC's global 'failure number' counter and an ApiConnectRecord's local failure number to detect when a node failure has occurred since a transaction started, to detect and cleanup transactions which were in transient states when the node failure was detected. However it is observed that testNodeRestart -n TransStallTimeout fails occasionally in the COMPLETE phase - a transaction blocked in the COMPLETE phase is unblocked by normal COMPLETE timeout handling. Investigation shows that the problem is that in some cases the ApiConnectRecord's failure number is not initialised. This is because the COMPLETE phase uses a different ApiConnectRecord (Copy record) than the PREPARE + COMMIT phases, to allow the PREPARE + COMMIT record to be used for a new transaction concurrently with COMPLETE. Solution Ensure that the Copy ApiConnectRecord has an initialised Failure number. Change-Id: I725d80bb3230eeeeb3c3e357943738dfdfc3f434
Change-Id: I5b889ae50f69341f051e27bfec3532eded79eada
WHEN SLAVE RECONNECTS Description: ------------ In a source-replica setup, when the replica reconnects to the source, a "killing the zombie dump thread" message appears in the source's error log. Despite this message, both servers continue to operate normally. Analysis: ------------ This is expected behavior, but the message could be made clearer: The term "zombie dump thread" is likely an internal term and should be avoided. The message should clearly indicate, through its text (not just the severity level), that this is a normal, expected condition. The text should make it clear that this most likely indicates the same replica is reconnecting. Fix: ---- Update the message with clearer and more meaningful text. Change-Id: Id5808be9cbe9e8fa41da5313ad5e5eeaa37d3bf8
Merge branch 'mysql-5.7-cluster-7.6' into mysql-8.0
PS-9614 Pool-of-Threads' timer thread fails to start if mysqld is sta…
Revert to upstream solution.
… opt_trace.general_ps_prot_all The same MTR tests fail with MySQL 8.0.41. Oracle forgot to rewrite these tests.
…while server shutdown (#5549) https://perconadev.atlassian.net/browse/PS-9611 Changed max value of the 'masking_functions.dictionaries_flush_interval_seconds' variable: instead of 'ULLONG_MAX' we now limit it to 60 * 60 * 24 * 365 seconds = 31 536 000 seconds (1 year). Improved 'is_terminated_lambda' in the 'dictionary_flusher_thread' - we now also check for additional server termination conditions. Improved how 'dictionary_flusher_thread' reloads cache - before executing dictionary table SELECT, we now always reset diagnostic area in THD object to an empty state. Added new 'enable_masking_functions_flush_thread_turbo_mode' DBUG option which helps to simulate continuous (without delays) cache reload. Added new 'component_masking_functions.flusher_thread_da_cleanup' MTR test case which simulates the scenario reported in the bug description. Added new checks to the 'component_masking_functions.sys_var_dictionaries_flush_interval_seconds_basic' MTR test case - we now check for min and max values of the 'dictionaries_flush_interval_seconds' variable.
PKG-223 Packaging for release - 8.0.41-32
PKG-223 Packaging for release - 8.0.41-32
Access to /proc/$pid/task/$thread_id/mem is required by stacktrace code. We apply the same changes as upstream did at mysql/mysql-server@b76c48b031d
https://perconadev.atlassian.net/browse/PXC-4593 Merge with conflicts Merge remote-tracking branch 'percona/ps/release-8.0.41-32' into PXC-4593 # Conflicts: # README.md # build-ps/build-binary.sh # build-ps/debian/rules # build-ps/percona-server-8.0_builder.sh # build-ps/percona-server.spec # build-ps/rpm/mysql-5.7-sharedlib-rename.patch # man/ndb_blob_tool.1 # man/ndb_config.1 # man/ndb_delete_all.1 # man/ndb_desc.1 # man/ndb_drop_index.1 # man/ndb_drop_table.1 # man/ndb_error_reporter.1 # man/ndb_import.1 # man/ndb_index_stat.1 # man/ndb_mgm.1 # man/ndb_mgmd.8 # man/ndb_move_data.1 # man/ndb_perror.1 # man/ndb_print_backup_file.1 # man/ndb_print_file.1 # man/ndb_print_frag_file.1 # man/ndb_print_schema_file.1 # man/ndb_print_sys_file.1 # man/ndb_redo_log_reader.1 # man/ndb_restore.1 # man/ndb_secretsfile_reader.1 # man/ndb_select_all.1 # man/ndb_select_count.1 # man/ndb_show_tables.1 # man/ndb_size.pl.1 # man/ndb_top.1 # man/ndb_waiter.1 # man/ndbd.8 # man/ndbinfo_select_all.1 # man/ndbmtd.8 # man/ndbxfrm.1 # sql/auth/sql_user.cc
https://perconadev.atlassian.net/browse/PXC-4593 Conflicts resolved. Compilation fixed.
https://perconadev.atlassian.net/browse/PXC-4593 Galera repo pointer updated (galera-26.4.21)
https://perconadev.atlassian.net/browse/PXC-4593 MTR tests fixes: 1. disable_ahi_other_blocks disabled because it needs 4k InnoDB page 2. re-records because of missing re-record in fix for PXC-4573: main.grant_dynamic galera.galera_defaults perfschema.privilege_table_io 3. WSREP thread user explicitly specified as 'system user'. This is because of upstream commit 174795e that changed the logic of setting 'system user' as the executing user in processlist table. Previously WSREP threads had to have 'root' user set (commit de17518, PXC-4179) Tests re-recorded. 4. Upstream commit 174795e also changed the way of reporting Host in processlist table. Now it is empty instead of NULL. Tests re-recorded 5. Upstream commit 1b11bb9 changed the logic of handing view dropping. Necessary adjustments implemented in sql_view.cc 6. Fixed unit test WsrepAsyncMonitorTest.LeaveSequenceNumberMismatch for release build. The test expects the process to die, but in release build assert() evaluatest to noop and unireg_abort is not executed during unit test execution.
https://perconadev.atlassian.net/browse/PXC-4469 Implemented SST method using clone plugin.
PXC-4469: Implement CLONE method for SST
PKG-494 Add netcat dependency to debian packages
# Conflicts: # mysql-test/r/grant_dynamic.result # mysql-test/suite/perfschema/r/privilege_table_io.result
https://perconadev.atlassian.net/browse/PXC-4469 Post push fix. Problem: mysql client version check used incorrect way of versions comparison. Cause: Comparison metod used -lt that works for integers. We need lexicographic comparison. Solution: Changed to use already existing 'compare_versions' function from wsrep_sst_common.sh Additionally fixed MTR test.
It produces unmanagable flood of warnings. The issue should be addressed separately.
|
aibek.bukabayev [email protected] seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
kamil-holubicki
requested review from
venkatesh-prasad-v and
VarunNagaraju
and removed request for
venkatesh-prasad-v
venkatesh-prasad-v
approved these changes
Feb 27, 2025
VarunNagaraju
approved these changes
Feb 27, 2025
kamil-holubicki
merged commit 3e8396e
into
percona:release-8.0.41
23 of 27 checks passed
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.