This repository was archived by the owner on Feb 10, 2023. It is now read-only.
MySQL release 5.7.26 29 #12
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
PS-4758: A sequence of LOCK TABLES FOR BACKUP and STOP SLAVE SQL_THREAD
This is a backport from 8.0, updated libevent to 2.1.8 Change-Id: Id42e713576e92696a9f226bb20df302d13d9ea47
Problem ======= Replication breaks when 'GRANT SELECT' is executed on master when column names are keywords. Analysis ======== On master, column names in GRANT query were not quoted properly while writing to the binary log, leading to syntax error on slave. Fix === For GRANT commands, column names are properly quoted before writing to the binary log.
Post-push fix: ensure that libevent is always built with -fPIC Change-Id: If7bcee4ee699b018c1b041eccf565ab5402781fc
… ANYMORE Background: In BUG#25364806 mysqld_safe was changed to pass relative path for pid file location. This uncovered a bug in mysqladmin. The tool used a plain SQL query to pid file location, however this will merely return the value of the pidfile *option*, server does additional manipulation to get final location of pid file. Fix: Resolve location to pid file in the same way as server itself does. Add test case using mysqladmin shutdown and verification of absent pid file.
PS-5158 : *** buffer overflow detected *** in mysqld on INSERT query
PS-4855 (Replace http with https in http://bugs.percona.com in server…
PS-3672 / PS-3673 / PS-3568 / PS-3535 in preparation for PS-5041 / PS…
… ANYMORE Post push fix: 5.6 and 5.7: skip added test for embedded 5.7+: output has extra prefix
…NAMED PIPES ENABLED Problem ------- The default named_pipe_full_access_group value of 'everyone' is only a valid Windows group name on English installations of Windows. Attempting to start MySQL server on a non-English Windows installation with named pipes enabled and using the default named_pipe_full_access_group value will fail. Fix
[post-push] Problem ------- The test script binlog_gtid.binlog_gtid_unknown_xid is failling sporadically on PB2 due to a difference in expect error codes: mysqltest: At line 110: Query 'XA ROLLBACK 'xa1'' failed with wrong error 1397: 'XAER_NOTA: Unknown XID', should have failed with error '1399'. Analysis -------- This problem happens when the test is ran several times in a row, leading to the conclusion that something has not been cleaned up properly. After analysis, the conclusion is that an XA transaction that is started in the test script is never commited or rolled back. Fix --- 1) Rollback the XA transaction at the end of the test script 2) Verify that are no pending XA transactions
Group Replication has a README file which is mostly forgotten, the 8.0 version still mentions 5.7 for instance. This README file was created with the assumption that the plugin would be released stand-alone, which didn't happen. Resolution: The server root has a minimalist README file that points to documentation, which covers all code. To avoid a not-updated file to be released we will remove the GR plugin README file.
(cherry picked from commit 0a81167b41a016f4720242bd1afd07fd26547103)
…NAMED PIPES ENABLED Problem ------- The default named_pipe_full_access_group value of 'everyone' is only a valid Windows group name on English installations of Windows. Attempting to start MySQL server on a non-English Windows installation with named pipes enabled and using the default named_pipe_full_access_group value will fail. Fix (cherry picked from commit b14effdf8438e13770afe27e715e1584581c6acd)
1. Use Xenial image and modify addresses of repos to Xenial 2. Force to check a commit if `last_commit.txt` is not found for the trunk (solves issues when `Auto cancel branch builds` is turned on for Travis CI) 3. Remove less frequently updated `ppa:jonathonf/gcc`
main.mysqldump started failing as we entered 2019 as it contained the creation of an event starting 31/12/2018, which now is in the past. Fix this by kicking the can 11 years down the road... Change-Id: I9a19d218dba117595af587f8fa9de86554fc738c
Change-Id: I7a7576d6e33e0e5a359eee4de32ef8bc06bcca4e
PS-5165: Use Xenial instead of Trusty in Travis-CI (5.6)
Fix PS-5269 (5.6 ASan: intermittent thread stack overrun on two MTR t…
Fix PS-5268 (main.mysqldump is failing because of dropped event)
…E TO A SERVER
Problem
========================================================================
Running the GCS tests with ASAN seldomly reports a user-after-free of
the server reference that the acceptor_learner_task uses.
Here is an excerpt of ASAN's output:
==43936==ERROR: AddressSanitizer: heap-use-after-free on address 0x63100021c840 at pc 0x000000530ff8 bp 0x7fc0427e8530 sp 0x7fc0427e8520
WRITE of size 8 at 0x63100021c840 thread T3
#0 0x530ff7 in server_detected /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:962
#1 0x533814 in buffered_read_bytes /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:1249
#2 0x5481af in buffered_read_msg /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:1399
xelabs#3 0x51e171 in acceptor_learner_task /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:4690
xelabs#4 0x562357 in task_loop /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/task.c:1140
xelabs#5 0x5003b2 in xcom_taskmain2 /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:1324
xelabs#6 0x6a278a in Gcs_xcom_proxy_impl::xcom_init(unsigned short, node_address*) /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_proxy.cc:164
xelabs#7 0x59b3c1 in xcom_taskmain_startup /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_control_interface.cc:107
xelabs#8 0x7fc04a2e4dd4 in start_thread (/lib64/libpthread.so.0+0x7dd4)
xelabs#9 0x7fc047ff2bfc in __clone (/lib64/libc.so.6+0xfebfc)
0x63100021c840 is located 64 bytes inside of 65688-byte region [0x63100021c800,0x63100022c898)
freed by thread T3 here:
#0 0x7fc04a5d7508 in __interceptor_free (/lib64/libasan.so.4+0xde508)
#1 0x52cf86 in freesrv /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:836
#2 0x52ea78 in srv_unref /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:868
xelabs#3 0x524c30 in reply_handler_task /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:4914
xelabs#4 0x562357 in task_loop /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/task.c:1140
xelabs#5 0x5003b2 in xcom_taskmain2 /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:1324
xelabs#6 0x6a278a in Gcs_xcom_proxy_impl::xcom_init(unsigned short, node_address*) /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_proxy.cc:164
xelabs#7 0x59b3c1 in xcom_taskmain_startup /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_control_interface.cc:107
xelabs#8 0x7fc04a2e4dd4 in start_thread (/lib64/libpthread.so.0+0x7dd4)
previously allocated by thread T3 here:
#0 0x7fc04a5d7a88 in __interceptor_calloc (/lib64/libasan.so.4+0xdea88)
#1 0x543604 in mksrv /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:721
#2 0x543b4c in addsrv /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:755
xelabs#3 0x54af61 in update_servers /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_transport.c:1747
xelabs#4 0x501082 in site_install_action /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:1572
xelabs#5 0x55447c in import_config /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/site_def.c:486
xelabs#6 0x506dfc in handle_x_snapshot /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:5257
xelabs#7 0x50c444 in xcom_fsm /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:5325
xelabs#8 0x516c36 in dispatch_op /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:4510
xelabs#9 0x521997 in acceptor_learner_task /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:4772
xelabs#10 0x562357 in task_loop /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/task.c:1140
xelabs#11 0x5003b2 in xcom_taskmain2 /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/xcom/xcom_base.c:1324
xelabs#12 0x6a278a in Gcs_xcom_proxy_impl::xcom_init(unsigned short, node_address*) /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_proxy.cc:164
xelabs#13 0x59b3c1 in xcom_taskmain_startup /home/tvale/mysql/plugin/group_replication/libmysqlgcs/src/bindings/xcom/gcs_xcom_control_interface.cc:107
xelabs#14 0x7fc04a2e4dd4 in start_thread (/lib64/libpthread.so.0+0x7dd4)
Analysis
========================================================================
The server structure is reference counted by the associated sender_task
and reply_handler_task.
When they finish, they unreference the server, which leads to its memory
being freed.
However, the acceptor_learner_task keeps a "naked" reference to the
server structure.
Under the right ordering of operations, i.e. the sender_task and
reply_handler_task terminating after the acceptor_learner_task acquires,
but before it uses, the reference to the server structure, leads to the
acceptor_learner_task accessing the server structure after it has been
freed.
Solution
========================================================================
Let the acceptor_learner_task also reference count the server structure
so it is not freed while still in use.
Reviewed-by: André Negrão <[email protected]>
Reviewed-by: Venkatesh Venugopal <[email protected]>
RB: 21209
Fix PS-5271 (5.6 ASan: intermittent thread stack overrun on rpl.rpl_r…
Add testcase for upstream bug 88797
KEYRING_OKV_OPEN_MODE=1 DESCRIPTION =========== An attempt to migrate keyring using keyring_okv plugin would result in server throwing error: unknown variable 'keyring_okv_open_mode=1'. ANALYSIS ======== Patch to Bug#28339014 makes keyring migration server set the variable 'open_mode' for all keyring plugins. This var was added in all the keyring plugins except okv, and hence this error. FIX === Introducing the same var in okv keyring plugin as done for the other keyring plugins, so that the server can set it for this plugin too. Please be noted that the var would however wont be used in plugin as such. Renamed the common variable 'keyring_file_open_mode' to 'keyring_open_mode' so that it is relevant for all keyring plugins. Also prefixed the keyword 'loose' to the variable <keyring>_open_mode.
…XT_FAST (SIMPLE + RELEASE). Issue here is, list iterator on a list pointing to nullptr tried to access nullptr to get element and resulted in a issue reported. When preparing a statement, if statement is a CREATE TABLE request with same name as already existing view then view definition parse is skipped while opening table and a dummy view lex is created but memory for TABLE_LIST::view_table is not allocated. Executing prepared statement in locked table mode, opens table and uses iterator over the TABLE_LIST::view_table in view definition parse code. Since TABLE_LIST::view_table is nullptr in this case, accessing element from it resulted in a issue reported. To fix this issue, allocating empty List<TABLE_LIST> instance for TABLE_LIST::view_table after creating the dummy view lex.
…phore wait > 600 assertion Problem: -------- A long running ALTER TABLE ADD INDEX with concurrent inserts causes sempahore waits and eventually crashes the server. To see this problem you need to have 1. A table with lots of data. Add index should take significant time to create many pages 2. Compressed table. This is becuase CPU is spent on compress() with mtr already latching index->lock More time spent by mtr, more waits by the INSERT. Helps in crash. 3. Concurrent inserts when ALTER is running. The inserts should happen specifically after the read phase of ALTER and after Bulk load index build (bottump build) started. The entire bulkload process latches the index->lock X mode for the whole duration of bottom up build of index. The index->lock is held across mtrs (because many pages are created during index build). An example is this: Page1 mtr latches index->lock X mode, when page is full, a sibling page is created. The sibling Page 2 (mtr) also acquires index->lock X mode. Recursive X latching is allowed by same thread. Now Page 1 mtr commits but index->lock is still held by Page 2. Now when page 2 is full, another sibling page is created. Sibling Page 3 now acquires index->lock X mode. Page 2 mtr commits.. This goes on and on. Also happens with Pages at non-root levels. Essentially the time index->lock is held is equally proportional to number of pages/mtrs created. And compress tables helps in making mtr take a bit more time in doing compress() and duration of each mtr is higher with compressed tables. At this stage, a concurrent INSERT comes and since there is concurrent DDL and the index is uncommited, this insert should go to online ALTER log. It tries to acquire index->lock in S mode. Bulk load index already took index->lock X mode and is not going to release it until is over. INSERT thread keeps on waiting, and when the wait crosses 600 seconds to acquire index->lock, it will crash. Fix: ---- INSERT thread acquires index->lock to check the index online status. During the bulk load index build, there is no concurrent insert or read. So there is no need to acquire index->lock at all. Bulk load index build is also used to create indexes in table rebuild cases. For example DROP COLUMN, ADD COLUMN. The indexes on intermediate table (#sql-ib..) are built using bulk load insert. A concurrent DMLs at this stage do not acquire index->lock. So acquiring index->lock on the intermediate table, which is not visible to anyone else doesn't block concurrent DMLs. Ideally we can try to remove all index->lock X acquisitions in bulk load index build path. We play *safe* and remove acquisitions only incase of uncommited indexes. The other path (bulk load used during rebuild) is not affected anyway.
PS-3410 : LP #1570114: Long running ALTER TABLE ADD INDEX causes sema…
Fix PS-5570 (Slow log data not cleared before COM_QUIT)
…y master) https://jira.percona.com/browse/PS-5353 Unlike a normal storage engine (e.g. 'InnoDB') in which 'rnd_next()' overload actually reads all data in BLOB fields from real storage into internal SE memory (like 'mem_heap' in InnoDB) and updates packed representation ('table->record[0]') of the BLOB field values with pointers to this internal SE memory, 'Blackhole' engine does not do this. In case when a database with 'Blackhole' tables serves just as an intermediate binlog server in a replication chain, this may cause data corruption. In particular, when 'Update_rows_log_event' is processed on a 'Blackhole' table, calling 'Update_rows_log_event::do_exec_row()' will first copy Before Image (BI) found in 'record[0]' into 'record[1]' and then unpack After Image (AI) into 'record[0]'. The problem is that this record copying is shallow (just 'memcpy()') and for packed BLOB fields it just copies pointer values. In other words, before calling 'unpack_current_row()' we end up in a situation when packed BLOB field values in 'record[0]' (AI) and 'record[1]' (BI) point to exactly the same memory location and calling 'unpack_current_row()' for AI overwrites BLOB data in BI. To prevent this we do the same trick as for virtual generated columns in 5.7 - keeping old BLOB value inside 'old_value' field in 'Field_blob' class by calling 'keep_old_value()' for all BLOB fields currently marked for update in 'table->write_set'. Added 'rpl.bug93917' MTR test case which simulates this scenario for various column types (all flavors of BLOB, all flavors of TEXT, VARCHAR and VARBINARY). Partially backported 'old_value' extension of the 'Field_blob' class from the WL #8149 "B-tree Index Support on non-materialized virtual columns" (commit mysql/mysql-server@c47e175).
…3-blackhole_blob Fixed PS-5353 (Wrong binlog entry for BLOB on a blackhole intermediary master) (5.7)
While the actual test failures are observed on 8.0, clean up the test in lower branches as well: for table and row lock waits, only slow-log the actual statements that wait for the locks, removing test coverage (and potential instability issues) from other commands.
- Changed TokuDB test generator makefiles to invoke python2 explicitly rather than generic python. - Changed TokuDB *.py scripts to she-bang with python2 instead of python. - Changed innodb_stress tests to invoke pythin2 explicitly rather than generic python.
- Changed MyRocks tests to invoke python2 explicitly rather than python.
https://jira.percona.com/browse/PS-5101 *** Updated man pages from MySQL Server 5.7.26 source tarball. *** Updated 'scripts/fill_help_tables.sql' from MySQL Server 5.7.26 source tarball.
…ercona-server into georgelorchpercona-ps-5.7-5550 - Partially reverted changes for RHEL8 that only s/python/python3 without changing tests to be python3 compatible. Changed to python2 instead.
Problem: -------- With native paritioning and index_merge, the native partition handler is cloned. One important point missed when fixing PS-5206 is that both the original and clone share the parition_info object (m_part_info). It has bitmap of partitions read and used. The cloned handler, which has reference to the shared to partition_info object, resets the partition bitmap during creation. This causes problem during the actual index scan. Fix: ---- 1. Create context to identify if the native partition handler creation is from clone or brand new. 2. When it is clone, do not reset the partition bitmaps (i.e avoid calling m_part_info->set_partition_bitmaps()). This is the core fix. 3. Additionally, we fix the cloned object creation to use clone mem_root instead of TABLE->mem_root. Optimizer can destroy the cloned handler immediately after its use. (See QUICK_RANGE_SELECT::~QUICK_RANGE_SELECT). So the memory used by cloned handler objects is freed immediately at end of query execution.
PS-5562 : index_merge + partitioning + MyRocks crashes the server
PS-5428 Use 'devtoolset-2' for centos6 i386
Issue: changed page tracking uses the LOG flag during read operations to follow the correct code path. Redo log encryption backported from 8.0 tries to decrypt pages with a certain bit set, and fails. While the end result is the same, the error log gets flooded with decryption errors. Solution: the NO_ENCRYPTION flag, previously ignored by log encryption now disables decryption during log reads too.
https://jira.percona.com/browse/PS-5101 *** Our fix for PS-3951 "Fix decreasing status counters" (https://jira.percona.com/browse/PS-3951) (commit b321f1e) left as is as it is identical to the upstream fix for the Bug #27839644 / #90351 "GLOBAL STATUS variables drift after rollback" (https://bugs.mysql.com/bug.php?id=90351) (commit mysql/mysql-server@91780f0). Out MTR test case 'main.bug90351' left intact. *** Reverted our fix for PS-5268 "main.mysqldump is failing because of dropped event" (https://jira.percona.com/browse/PS-5268) (commit a09875a) in favor of the upstream fix for the Bug #29159867 "MAIN.MYSQLDUMP FAILS WITH EVENT CREATED IN THE PAST" (commit mysql/mysql-server@274d19a). *** Reverted our fix for PS-4570 "Flush status; adds twice to global values" (https://jira.percona.com/browse/PS-4570) (commit 9b66cba) in favor of the upstream fix for the bug #28291258 / #91541 "'Flush status' statement adds twice to global values" (https://bugs.mysql.com/bug.php?id=91541) (commit mysql/mysql-server@a900a05). Our MTR test case 'perfschema.bug91541' also removed as it was added as the upstream extensions to 'perfschema.show_coverage' ("Bug #28291258" section). *** Our fix for PS-3906 "handle_fatal_signal (sig=11) in dict_index_is_auto_gen_clust | sql/signal_handler.cc:223" (https://jira.percona.com/browse/PS-3906) (commit de29427) left intact as it is identical to the upstream fix for the bug #27373959 / #89126 "create table panic on innobase_parse_hint_from_comment" (https://bugs.mysql.com/bug.php?id=89126) (commit mysql/mysql-server@02a1f20). Only minor space/tabs formatting changes. *** Our fix for PS-1812 "LP #1708033: heartbeats/fakerotate cause a forced sync_master_info" (https://jira.percona.com/browse/PS-1812) (commit 63d4f7f) left almost intact (only one change in 'force_mi_flush_info' parameter of the 'write_ignored_events_info_to_relay_log()' call inside 'handle_slave_io()' from 'true' to 'false') as it is identical to the upstream fix for the bug #28815555 / #85158 "heartbeats/fakerotate cause a forced sync_master_info" (https://bugs.mysql.com/bug.php?id=85158) (commit mysql/mysql-server@02a1f20). Our MTR test case 'rpl.bug85158' left intact. *** Fixed regression in 'main.join_file_handler' MTR test case. Reverted removal of the 'reinit_io_cache()' call inside 'Unique::get()' in 'sql/uniques.cc'. This call was originally removed as unnecessary as part of the PS-3947 "Refactor IO_CACHE layer to allow custom read/write function (Prerequisite for temporary file encryption)" (https://jira.percona.com/browse/PS-3947) implementation (commit f8157f3) but became an issue after Oracle fixed Bug #28039829 / #90902 "Select Query With Complex Joins Leaks File Handles" (https://bugs.mysql.com/bug.php?id=90902) (commit mysql/mysql-server@d009f1a8b5d). *** Added 'main.bug93388' MTR test case for the Bug #28986737 / #93388 "Renaming and replacing mysql.user table can lead to a server crash" fixed in 5.5.64, 5.6.44, 5.7.26, 8.0.16 (commit mysql/mysql-server@e02123c). A damaged mysql.user table could cause a server exit. *** Changes made to the 'mysql-test/suite/innodb/t/table_encrypt_5.test' file as part of the fix for Bug Bug#28330922 "KEYRING MIGRATION FAILS, BUT SAYS 'KEYRING MIGRATION SUCCESSFULL' + EMPTY FILE" (commit mysql/mysql-server@df75a4d) moved to the 'mysql-test/include/log_encrypt_5.inc'. Similar changes applied to 'mysql-test/include/log_encrypt_5.inc' and 'mysql-test/suite/innodb/t/table_encrypt_2_keyring-master.opt' as well. Re-recorded 'keyring_vault.table_encrypt_5' and 'keyring_vault.table_encrypt_5_directory' MTR test cases because of the changed include files. *** Improved stability of the 'auth_sec.keyring_file_data_qa' MTR test case. When it is run under a user who cas access to '/', additional error might be generated in the error log file. Fixed by adding a new 'mtr.add_suppression()'. *** Modified and re-recorded 'main.plugin-load-add-with-path' MTR test cases to support testing environments where '$PLUGIN_AUTH' and '$EXAMPLE_PLUGIN' are located in the same directory. The problem existed even before this upstream merge. However, because of the Bugs #26115002, #29178542 this test was always skipped. This bug was fixed by Oracle in 5.7.26 (commit mysql/mysql-server@00df405) (commit mysql/mysql-server@7b54ab7) (commit mysql/mysql-server@75c0c34) (commit mysql/mysql-server@f44bede) The binary file for the udf_example user-defined function was omitted from binary distributions. *** Removed 'mysql-test/suite/encryption/t/.swp' file added by mistake in one of the previous commits. *** VERSION raised to "5.7.26-29". univ.i version raised to "29". *** This merge also fixes PS-5007 "Memory leak in innochecksum utility detected by ASan" (https://jira.percona.com/browse/PS-5007) as corresponding upstream Bug #28917614 / #93164 "Memory leak in innochecksum utility detected by ASan" (https://bugs.mysql.com/bug.php?id=93164) was fixed in 5.7.26 (commit mysql/mysql-server@9e6c980). InnoDB: Memory leaks discovered in the innochecksum utility were removed.
Merge upstream 5.7.26 into Percona Server
PS-5541: Do not try to decrypt blocks in changed page tracking. (5.7)
The location of the IV was dependent on a sizeof, resulting in an incorrect data layout written in 32 bit builds.
PS-5610: Fix keyring redo encryption in 32 bit builds (5.7)
Add pkg-config dependency and fix rpm build
…rcona-server into MySQL-release-5.7.26-29 Percona Server release 5.7.26-29
|
LGTM |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.