PXC-5217 Packaging tasks for release - PXC 8.0.46#2333
Open
adivinho wants to merge 182 commits into
Open
Conversation
Approved-by: Bjorn Munch <bjorn.munch@oracle.com>
Approved-by: Bjorn Munch <bjorn.munch@oracle.com>
Change-Id: Ib024ed6904faacb0600e6db174cfe648091dd21b
Change-Id: Id10fbc01b1e57f5eb4da312fc564aa90f38a4bb2
Change-Id: I73ae358dd848af05e33010b407c744d2d01a5b36
Change-Id: I28ac34ad05289ac3795a482cd4ed3ef32db81e37
The MySQL function regexp_instr() has signature: REGEXP_INSTR(expr, pat[, pos[, occurrence[, return_option[, match_type]]]]) Add error check when evaluating 'return_option' in the prepare phase. Also evaluate it only once. Also add value check for return_option in the execution phase. Change-Id: I49dc9ad9c15970f7d89ca23c554160d4e1c06205 (cherry picked from commit 0910beaf86202a5c1993f3152a124d6c0399219a)
Approved-by: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Approved-by: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com>
Modify ndb_restore to apply backup log records concurrently.
Problem :
A data node backup is comprised of one or more PARTs,
depending on the number of LDMs in the backed up data
node.
Each part comprises a CTL file, a DATA file and a LOG file.
ndb_restore uses a thread to restore each PART of a data
node backup.
During DATA file restore, each ndb_restore thread restores
rows in the DATA file concurrently, according to the passed
--parallelism parameter.
During LOG file restore, each ndb_restore thread restores
log events in the LOG file serially.
Restoring log events serially can take some time when the
LOG file has a large number of entries.
Solution
ndb_restore is modified to restore LOG file events
concurrently from each thread, in a similar way to the
concurrency used for the rows in the DATA file.
An extra transaction scheduler component is added to
ensure that LOG restore remains ordered + serialised
on a per-row basis.
Details
ndb_restore_debug modified to give some coverage
checking concurrent log record application,
specifically the order of application.
Refactored 'extra storage buffer' in consumer_restore so that
it can be used as part of DATA or LOG iteration.
Modified Log Iterator to use extra row buffer for log apply.
This prepares it for later having > 1 operation in flight at once
Modified ndb_restore to copy LogEntry content into the 'callback'
transaction object rather than relying on the iterator being
positioned on the same callback object.
Modified log entry apply to define multiple concurrent transactions.
The buffering + execution model used is the same as DATA restore.
- The Log iterator will provide LogEntrys to the consumer(s)
- The Log iterator will use a configurable size of file read
buffer
- consumer_restore will :
- Define an NdbApi transaction to perform the action
- Prepare the transaction
- Transactions will be sent to data nodes either :
- When all free transactions (parallelism) are defined
- When the iterator needs to free the underlying data
- The async API is used to execute transactions
- At end of log entry iteration, all outstanding NdbApi
transactions are processed and their results waited for.
The existing tuple_free() method on consumer is renamed
to data_free() to reflect that it is now used for both
tuple and log entry iteration.
Concurrent log apply can cause log apply errors to be detected
later (in endLogEntrys()), resulting in a different error message.
Modified ndb_restore_debug test to check for this.
Concurrent log apply can cause all log apply events to be defined
before any are complete, so that using the # of completed events
to trigger an error-insert is unreliable.
Modified the error-insert to use the number of defined events
instead.
Modify log entry apply functionality to calculate a (table+) primary
key hash for each log entry as a side effect of defining the NdbApi
operation, and store it in the callback transaction object.
- Log entry content can vary depending on type (I, U, D), with key
columns contained > once in some cases.
- MySQL standard hash functions are used, giving e.g. collation
safe hashing.
- This is similar to hashing added to NdbApi for detecting multiple writes
to the same Blob in an operation batch.
- The hash value is considered a coarse-grained row identity for
the operation with the properties :
- Two operations (I, U, D) on the same row in the same table
will have the same hash value.
- Can be used to find operations affecting the same row
- Two operations (I, U, D) on the same pk in a different table
will (likely) have a different hash value.
- Does not over serialise where the same pk is used in
operations on different tables
- Two operations (I, U, D) on different pks will (likely) have
a different hash value.
- Does not over serialise
Existing per-log event processing is split into :
logentry_a() :
Define NdbApi operation
Determine row identity value (hash of table id, primary key values)
Ask transaction scheduler for permission to execute
Yes : call logentry_b()
No : transaction is queued, return and read next log event
logentry_b() :
Prepare NdbApi operation to be sent to data nodes
The logentry application callback is modified to notify the
transaction scheduler that the transaction has completed.
The transaction scheduler may return a transaction that was
waiting for this completion, which must now be executed by
calling logentry_b()
Solution properties
- Log operation transactions against different rows can be
executed concurrently by a single ndb_restore thread
- Only one transaction against a single row can be executed
at a time
Others will be queued up, and executed serially when the
current transaction on that row completes.
- In the retry case (temporary error), the current active
transaction stays active, and the queued transactions stay
queued.
A sanity check that the calculated hash remains the same
is added.
- A hash of the log event's table id and primary key values
are used as the 'row identity'.
There can be hash collisions where two different rows have
the same hash value. This will not cause functional problems
and is ignored.
- The most extreme serialisation would occur when all log
operations are for the same row, and then all transactions
are defined and queued serially. This devolves into the
previous fully serial implementation.
Change-Id: Ie64817d59df33b32ae3904eb69b1a9cf49f89d67
Flint++ tool's static analysis of InnoDB sources Description: Flint++ is a static analysis tool that scans C/C++ source code and warns about potential issues. It provides extra diagnostics focused on code cleanliness, safety, portability, and correctness. Issues: 1) Move constructors should not take a const argument. 2) Symbol SYS_COLUMN__PRTYPE invalid. 3) Copy constructors should take a const argument. Fix: 1) A move constructor must accept T&& (non-const) because moving typically requires modifying the source object. Using const T&& prevents moving and causes the move constructor to behave as a copy, defeating its purpose. This patch updates the signature to T&&, enabling proper move semantics. 2) Use of double underscore is reserved by the C/C++ standards for the implementation (compiler, standard library, system headers). Renamed the macro to SYS_COLUMN_PRTYPE to comply with standard naming rules. 3) Copy constructors must accept const T& so they can copy from const objects and rvalues bound to const references. Using a non-const reference makes the type editable in multiple scenarios and breaks standard copy semantics. This change restores correct C++ behavior. Change-Id: Ia139ef6a3dc1964c5e193bb2f7cb12437acd252f
Symptom: The test innodb.innodb_dirty_pages_at_shutdown fails sporadically with MTR reporting 'Command "shutdown_server" failed with error 2' Root Cause: The error 2 indicates that the shutdown command timed out after waiting for 60 seconds. The test expects the server to crash during the last phase of shutdown. A core file is generated when the server crashes. The timeout is hit when shutdown takes too long due to generation of core file. Fix: Disable the generation of core file as it is not required for the test. Change-Id: I37f9777b97f564b49cfddfa7271258f974df6053
…when node rejoins Modify node failure handling for survivor node TCs to wait until their inflight transactions involving a failed node are complete before recording the node failure as completed. This avoids any risk that the failure handling is still in progress when a node rejoins. Change-Id: Ia5265b3f613811e3b2b5665469ae061113f61439
…when node rejoins Added logging for the two phases of NF_CHECK_TRANSACTION failure handling including the number of transactions needed to be waited for in second phase. 2025-12-19T22: 19:49.434507Z [ndbd] INFO -- DBTC 3: Step NF_CHECK_TRANSACTION identified 1 transactions where failed node 1 participated which are now being committed or rolled back. 2025-12-19T22: 19:49.434563Z [ndbd] INFO -- DBTC 2: Step NF_CHECK_TRANSACTION identified 2 transactions where failed node 1 participated which are now being committed or rolled back. 2025-12-19T22: 19:49.434768Z [ndbd] INFO -- DBTC 1: Step NF_CHECK_TRANSACTION identified 1 transactions where failed node 1 participated which are now being committed or rolled back. 2025-12-19T22: 19:49.434820Z [ndbd] INFO -- DBTC 1: Step NF_CHECK_TRANSACTION all transactions where failed node 1 participated are now either committed or rolled back. 2025-12-19T22: 19:49.434822Z [ndbd] INFO -- DBTC 1: Step NF_CHECK_TRANSACTION completed, failure handling for node 1 waiting for NF_TAKEOVER. 2025-12-19T22: 19:49.489119Z [ndbd] INFO -- DBTC 3: Step NF_CHECK_TRANSACTION all transactions where failed node 1 participated are now either committed or rolled back. 2025-12-19T22: 19:49.489124Z [ndbd] INFO -- DBTC 3: Step NF_CHECK_TRANSACTION completed, failure handling for node 1 waiting for NF_TAKEOVER. 2025-12-19T22: 19:49.489334Z [ndbd] INFO -- DBTC 2: Step NF_CHECK_TRANSACTION all transactions where failed node 1 participated are now either committed or rolled back. 2025-12-19T22: 19:49.489337Z [ndbd] INFO -- DBTC 2: Step NF_CHECK_TRANSACTION completed, failure handling for node 1 waiting for NF_TAKEOVER. Change-Id: If44d18954297075e63765d265bda17af6d0a881f
…when node rejoins Error insert 8127 used to show slow NodeFailCheckTransactions processing which can still be running when node recovers leading to problems. Change-Id: I0cb8ac11114ac534bd42cc95a15a72bf7c3bc401
…when node rejoins New test testNodeRestart -n PreparedUpdatesNF. Test prepares transactions with many updates. When a node that participate in the transaction but is not the transaction coordinator node the transaction will be aborted as part of node fail handling on the transaction coordinator node. Before fix the node fail handling could end before transaction was aborted. Change-Id: I4b60c54ca664dc543ecb71ba01d4c59cb833bd61
Modify error output to avoid chance of interleaving. Change-Id: I02a57fb941cbf3610043e34fdd8594db8ff7dc18
Follow up fix for compilation error due to extra ; outside of a function. Change-Id: Ibb1d29a93fc5ee20816af59b0164f491332005f3
Problem: There is a race between the NDB binlog injector and the NDB binlog purger that can leave a stale row in mysql.ndb_binlog_index for a binlog file that has just been purged. Sequence: 1. The NDB injector session commits the epoch transaction to the binlog and determines the binlog file name for that commit. 2. The NDB injector session then uses a separate transaction to write that file name into mysql.ndb_binlog_index (InnoDB). Because steps (1) and (2) are two different transactions, the purger can start and complete its removal for that File in between (1) and (2). In that case, the purger will not see the row inserted in (2), leaving a single orphan row for the just‑purged file. Analysis: The purger should wait until NDB binlog has stopped using the binlog file which is about to be purged. Since NDB binlog usage of file to be purged is very rare, the solution needs to be lightweight and only activate when purger is requesting the current binlog file name. Solution: Extend NDB binlog with functionality to publish the current binlog file name "in use" when someone is waiting for it. Make the purger wait until the ndb binlog is not using the binlog file to be purged. This patch also extends rpl_injector with functionality to get the current binlog file name, this effectively encapsulates all acess to binlog.h which can thus be removed from other place. Change-Id: Ic70b7ebf1508c39945e1dff8bed5eaaf722512a6
MySQL 8.0+ parser consumes significantly more memory than 5.7 for queries with large IN clauses. With 10 million values: - MySQL 5.7: 2,213 MB - MySQL 8.0/9.x: 34,278 MB (15.5x worse) The issue is caused by mem_root_deque's linear growth strategy. When the blocks array needs to grow, it allocates a new array with just one additional slot. Since MEM_ROOT cannot free individual allocations, each reallocation leaves the old array wasted. With N blocks, this creates O(N) reallocations and O(N^2) cumulative memory waste. The fix implements exponential growth with independent growth factors for each direction: 1. Add m_blocks_allocated to track total array capacity 2. Add m_first_block_idx to track where used blocks start 3. Add m_back_growth_exp and m_front_growth_exp (uint8_t) to track growth history for each direction independently 4. When push_back triggers growth, add 2^m_back_growth_exp spare slots at back, then increment the exponent 5. When push_front triggers growth, add 2^m_front_growth_exp spare slots at front, then increment the exponent This gives amortized O(1) insertions with O(log N) reallocations, reducing cumulative memory waste from O(N^2) to O(N). Results after fix (10 million IN clause values): - MySQL 9.x: 3,147 MB (10.9x improvement vs unfixed 8.0/9.x) - Memory now scales linearly with input size Change-Id: I4781433ed5311b5493c7ac2edc1cb6d7dc97157f (cherry picked from commit 39a3ccb626bca65e8d14cd3f091165f75d036b7f)
with deterministic stored function EXPLAIN SELECT could crash the server when run on queries with GROUP BY containing a deterministic stored function. The crash was introduced by commit 22961101b82a (Bug#37560280 fix), which prevented EXPLAIN from executing stored functions. However, the fix did not account for the interaction with find_order_in_list() in sql_resolver.cc. The issue occurred because: 1. find_order_in_list() only adds ORDER/GROUP BY items to the fields list if !const_for_execution() 2. For deterministic stored functions, const_for_execution() returns true, so the item is NOT added to fields list 3. Without being in fields list, result_field is never set 4. create_tmp_table() calls get_tmp_table_field() which returns NULL, causing a crash in init_from_field() The fix modifies find_order_in_list() to also add items to the fields list when: - Running in EXPLAIN mode (not EXPLAIN ANALYZE), AND - The item contains a stored program This ensures result_field is properly set during temp table creation, preventing the NULL pointer dereference. Change-Id: I1f79aedd199d480984eb63a410ea38bbae367aec (cherry picked from commit 38e03ab4cc21189d73b307f7d363c4bb9fb022f0)
Query_expression::optimize This is a regression from the bugfix for Bug#35284734. The fix for Bug#35284734 was over counting the reference count for the underlying items of ref items for the cases when these items were part of the conditions added as part of IN to EXISTS transformation. As a result of the overcounting, an aggregate function was not removed, but the subquery that it was part of was removed because of an always false condition. This lead to problems later. The fix for Bug#35284734 was overcouting because it would increment the reference count of an item everytime an expression is marked as an expression created by IN-TO-EXISTS tranformation. However these expressions could be part of the condition that gets added to the query and when that condition is created, it is again set as created by IN-To-EXISTS there by leading to double counting. So the fix is to revert the change introduced by Bug#35284374 and introduce a more targetted reference counting during the transformation. Change-Id: Ic2bc3278d8b2c8542e8a12092bb1170cc71758b8
Patch for 8.0 Updated copyright headers to year 2026. Change-Id: Ibcc3475bb4c58d246d239986b668194f9f536aa1
…imit when locked for backup Description: ------------ In a source–replica setup, it was observed that the replica is deadlocked when the relay log exceeds `relay_log_space_limit` while `LOCK INSTANCE FOR BACKUP` is held on the replica. Analysis: ------------ A deadlock occurs between the replica IO thread and the SQL thread due to a missed relay log purge retry after the instance backup lock is released. Resulting Condition: - The relay log exceeds `relay_log_space_limit` while `LOCK INSTANCE FOR BACKUP` is held on the replica. - The IO thread remains blocked, waiting for relay log space to be freed. - The SQL thread remains blocked, waiting for new relay log events. - No condition variable is signaled and no retry path is triggered. - As a result, both threads remain blocked indefinitely, and replication makes no further progress. Fix: ---- Ensure that the relay log purge is retried if the IO thread is waiting due to relay_log_space_limit after the instance backup lock is released. This allows both the IO and SQL threads to resume and replication to progress. Change-Id: Ieeca7b3e7ac56afa4827d83a483276b074e8d03d
Patch for 8.0 - remaining outliers Updated copyright headers to year 2026. Change-Id: Iead0a7c23d2795329b34672ae542ee9992b802a9
Description: This commit is a backport effort for Bug#35784192, which enabled purge to skip the read_only check, required for undo log truncation on replica Fix: The include filenames differ between 8.0 and 8.4 Change-Id: I61b1b2684a6ca63e62faf6ca0785e230d6a6f7e7
…he-sha2 is missing in X Description =========== The implementation of WL#14281 (configuration caching_sha2_password_digest_rounds), defines how many times the hashing algorithm should iterate over HMAC function to generate digest that is stored in users authentication data. The effect of this variable was only added server, where X was left with default number of iterations. Fix === Adds support of cache-sha2-password accounts that were created with different number of difests rounds. Change-Id: I4a30cb73c80b591930f374e63b10e6c2b21cd529
Test fails occasionally with error :
Failed to open index NDB$RESTORE_PK_MAPPING from NDB due to error 4243: Index
not found
Problem
NDB$RESTORE_PK_MAPPING indexes can be created dynamically on tables being
restored by ndb_restore threads when they determine the need.
Each ndb_restore thread runs the table_compatible_check()
function which lists indexes on each table and then opens them
to determine whether the table has any unique indexes so that
a warning can be produced about the risk of restore failure.
The table_compatible_check() is run in every ndb_restore thread in
each ndb_restore process.
If one ndb_restore thread runs listIndexes(), open() while
another is building the NDB$RESTORE_PK_MAPPING index on a
table then it may :
- Observe that the index object exists
(In e.g. StateBuilding)
- Fail to open the index as it is not in StateOnline
This failure causes the restore thread to fail.
Solution
Modify table_compatible_check() to ignore
the NDB$RESTORE_PK_MAPPING index.
-> No problems opening while it's being built
-> No incorrect reporting that the table still
has a unique index
Change-Id: Ice871548d57a3e402fbc86ab2504a6dccdc5211c
https://perconadev.atlassian.net/browse/PXC-5213 Updated galera and wsrep-lib repo pointers.
https://perconadev.atlassian.net/browse/PXC-5213 Fixed tests affected by change 6d6a437e in Galera. Fixed potentially dangling pointer existence at the end of sst_joiner_thread(). It could be dereferenced in wsrep_sst_cancel() from the different context causing SIGSEGV.
https://perconadev.atlassian.net/browse/PXC-5213 Stabilized galera_garbd_invalid_param_value test (partial cherry pick of 16c6223) Stabilized galera_wan test.
https://perconadev.atlassian.net/browse/PXC-5213 Adjusted MTR suites split among Jenkins workers.
…LogHandler)
The NDB logger-t unit test intermittently failed in the parallel ctest run:
Logger.cpp:566: require((getLastLogMsg(file) == expected_msg)) failed
at the end of the BufferedLogHandler stress test. The test runs reliably in
isolation (verified) and only failed under heavy concurrent load, i.e. it is a
test-robustness issue, not a product bug. It is unrelated to the upstream merge.
After flushing 1000 buffered async messages and draining the buffer, the test
logs one final message, waits a single fixed interval (100ms) and then checks
that it is the last line in the log. This is fragile under load for two reasons:
- The BufferedLogHandler flushes asynchronously, so a single wait interval may
not be enough for the final message to reach the file.
- getLastLogMsg() reads from a fixed offset to EOF, assuming the file holds
exactly one line (it clears the file after every read to maintain that).
If the async thread flushes leftover buffered messages together with the
final one, the file briefly holds several lines and the comparison can
never match.
Make the final assertion robust:
- Add getLastLogLine(), which returns the message part of the last non-empty
line without clearing the file, so it is correct even when several messages
were flushed at once and the message being awaited is not truncated away.
- Replace the single fixed wait with a bounded retry loop (up to ~10s) that
polls until the final message appears.
Verified: passes standalone and 5/5 under heavy CPU contention (200 busy
stressors) that previously triggered the failure. Only the embedded unit test
is changed; BufferedLogHandler behavior is untouched.
…info
LogTimestampTest.iso8601 failed in Jenkins (RelWithDebInfo/debian:trixie/
x86_64):
Expected: "1970-01-01T01:00:00.000001+01:00"
Which is: "1970-01-01T00:00:00.000001-00:00"
Expected: "2011-07-07T02:00:00.000000+02:00"
Which is: "2011-07-07T00:00:00.000000-00:00"
The test sets TZ=CET and expects the system-time ISO 8601 timestamp to carry a
+01:00 (winter) / +02:00 (summer) offset. The bare name "CET" relies on the
system timezone database (/usr/share/zoneinfo/CET). On minimal build/CI
containers that file is not installed, so glibc parses "CET" as a POSIX zone
with no offset rule, i.e. UTC. localtime_r() then returns tm_gmtoff == 0, the
time is not shifted and the offset is formatted as "-00:00" (the sign defaults
to '-' for a zero offset) - exactly the observed output.
Replace the bare "CET" with a fully-specified POSIX TZ string,
"CET-1CEST,M3.5.0,M10.5.0/3" (CET in winter, CEST in summer using the EU DST
rule). glibc evaluates this without consulting the timezone database, so the
expected +01:00 / +02:00 offsets are produced regardless of which zoneinfo
files the host provides. This mirrors what the Windows branch of the test
already does (it uses a POSIX-style string rather than a bare zone name).
Verified: the test passes both with the system tz database present and with it
made unavailable (TZDIR pointing at an empty directory, which reproduces the
Jenkins failure with the previous code).
Note that while this issue is not observed on any Jenkins platforms which
are officially supported for 8.0, it still makes sense to apply this fix
to 8.0 branch, e.g. to avoid possible future problems with custom builds.
Test for bug#38928287 "CRASH INSIDE OF THE QUERY PARSER/PLANNER/RESOLVER" added in MySQL 8.0.46 causes stack overflow errors under ASAN. This is common issue for tests which check that we correctly detect and error out on potential stack overflows. Disabled the test for ASAN builds like it is done for other tests doing this (e.g. main.sp-error test).
Updated galera and wsrep-lib repo pointers. - recent fixes - galera updated to release_26.4.27
Percona Server release 8.0.46-37
https://perconadev.atlassian.net/browse/PXC-5213 LAsan suppression file updated. OpenSSL libcrypto holds global/lazy-init allocations for the process lifetime (released via atexit handlers on clean shutdown). When mysqld is killed by safe_process during PXC cluster teardown, those handlers never run and LSan reports them as leaks. The reported stack ends at CRYPTO_malloc because libcrypto.so is shipped without debug symbols, so suppress by that frame.
https://perconadev.atlassian.net/browse/PXC-5213 Updated galera and wsrep-lib repo pointers. Galera 4.27
…hes MySQL Router https://perconadev.atlassian.net/browse/PS-11329 Bug#39204635 mysql/mysql-server@6adc159923b Description =========== For X Protocol routing with `client_ssl_mode=PREFERRED` and `server_ssl_mode=AS_CLIENT`, a client can send `CON_CAPABILITIES_SET(tls=true)` after TLS is already active. Router accepted this second TLS capability request and re-entered the TLS upgrade path. During `tls_accept_finalize()`, the server-side TLS channel could already be initialized, which led to a `logic_error` and connection termination. Fix === Reject repeated TLS capability upgrades when client-side TLS is already active. For a second `tls=true` capability request, Router now returns error 5001 (`Capability prepare failed for 'tls'`) and continues normal session handling. Change-Id: Ifaaa93eeec1019160c7a6db50daa7e1af8f383c5 Co-authored-by: Lukasz Kotula <lukasz.kotula@oracle.com>
https://perconadev.atlassian.net/browse/PS-11329 Bug#39116965 mysql/mysql-server@5417e736ad9 Description: Connection attribute parsing read a length-encoded size field before checking that the complete field was present in the packet. Fix: A size check was added before reading the field. Debug coverage was added for short length-encoded attribute packets during pre-authentication. Change-Id: I08d69b0cfcbd38392a2826a4dd208320e89af5e9
https://perconadev.atlassian.net/browse/PS-11329 Raised MYSQL_VERSION_EXTRA to 38 in MYSQL_VERSION file. Raised PERCONA_INNODB_VERSION to 38 in univ.i file.
Backport 84 fixes
PXC-5213: Code refresh for - PXC 8.0.46
…60707 Moved Galera repo pointer
Apply the same packaging fixes made for PXC 8.4.10 (commits 59ad171 and 1f5bf4c): - debian/control: fix missing commas in Uploaders field (dpkg-source parse error). - Remove references to percona-xtradb-cluster-galera/packages/rpm/README and README-MySQL, which no longer exist upstream on the galera 4.x-8.0 branch; install the top-level README instead. - percona-xtradb-cluster.spec: split the libfido2.so.* file glob so the explicit %attr() mode is not applied to the libfido2.so.1 symlink. - Package %{_libdir}/mysql/libgalera_smm.so, installed by galera's own CMake subdirectory build in addition to the hand-copied galera4/ copy. - debian/rules: drop dead PXC 5.7-era packaging cruft (nm symbol dump into a nonexistent percona-xtradb-cluster-5.7 doc directory, and the now-removed packages/rpm/README copy). - pxc_builder.sh: fetch call-home.sh from a pinned commit with a sha256 checksum instead of an unauthenticated floating URL, and write it to a mktemp'd path instead of a fixed /tmp/call-home.sh. - pxc_builder.sh: patch the freshly checked out galera submodule's SConstruct to define GALERA_LOG_H_ENABLE_CXX globally, matching cmake/common.cmake, fixing an SCons build failure ('gu_error' was not declared in this scope in gcomm/gcache). Not applied here (needs separate verification for 8.0.46, since the extra/libkmip submodule is pinned to a different commit than 8.4.10): - packaging of libkmipclient.a/libkmipcore.a, which were confirmed as unpackaged files during an actual 8.4.10 build but may not have the same names in 8.0.46's libkmip version. - the percona-xtrabackup apt version bump, which doesn't map 1:1 since 8.0.46 pins different xtrabackup package versions/variants.
…_mode=ENFORCING" This reverts commit fa84530.
(8.0)Revert "PXC-5106: Set sql_require_primary_key=1 when using pxc_strict…
|
Keshav Jha 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. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.