Merge upstream 5.7.24 into Percona Server #2729
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
139686919030528 IN FILE TRX0TRX.IC LINE 213 Problem: In ha_innobase::end_stmt function, read & write operation on trx->lock.start_stmt is not protected by any mutex. Therefore if one thread is about to change trx->lock.start_stmt, other thread can see the inconsistent state of trx->lock.start_stmt. Fix: Added trx->mutex protection to make read & write on trx->lock.start_stmt a atomic operation. RB: #19697 Reviewed by : [email protected]
Description: ------------ MTR --manual-boot-gdb fails on mysql-5.7 builds. Issue: ------ When --manual-boot-gdb option is enabled, mysql and test directories are not created, causing the 'mysqld --bootstap' command to fail. Fix: ---- Create the directories for mysql and test database under datadir location before invoking gdb for mysqld bootstrap. Change-Id: I14a8560a3c16fde2f10910375a7e3bbef3d6bc0e
LONG SEMAPHORE WAIT Post Push fix for test case failure innodb_gis.rtree_rollback1 on weekly-5.7. Reviewed by : Debarun Banerjee<[email protected]> over IM.
… DEBUG
ASSERTION)
Problem:
--------
Replication P_S tables returns empty set when ORDER BY is
used.
Analysis:
---------
In replication P_S tables, the current position pointer to
the record was being used as an iterator for
fetching the records.
As a result, the current position
(table_replication_*::m_pos) of the record was getting
incremented in table_replication_*::rnd_next() and was
leading to PFS_engine_table::get_position() return the wrong
value to the Optimizer and hence was returning empty set.
Fix:
----
The current position pointer is made to point to the latest
record and is updated only when a new record is available.
Description ================= When group_replication_group_seeds contains a DNS based entry which resolves to it's on mysql daemon, group replication will be stuck. Configure a cluster with the following settings: group_replication_group_seeds = node1:33061,192.168.70.3:33061,192.168.70.4:33061 group_replication_local_address = 192.168.70.2:33061 And start it. I won't be able to start. Analysis ================= We already had that guard in place, but only if local_address matches seeds, either by both using name or both using address. If there is a mismatch, it would not work, as per the example above. Fix ================= Always resolve both local_address and seeds to address format before doing the comparision, and then skip if it matches the local address.
TO VARCHAR(40) INSTANTANEOUSLY
Analysis
========
Indexed VARCHAR columns are not expanded instantaneously (without index rebuild)for
InnoDB tables using INPLACE algorithm. The other problems uncovered as part of this
bug are:
a) Indexed VARCHAR columns when converted from unpacked
keys to packed keys(key size > 8 bytes) by expanding
the VARCHAR column was not instantaneous for InnoDB
tables using INPLACE algorithm even though pack keys
is a no-op for InnoDB tables.
b) CREATE/ALTER of InnoDB tables where the index size
exceeds the SE limit of 767 bytes for COMPACT or
REDUNDANT row_format did not report error in STRICT
mode and warning in non-strict mode.
SQL layer determines if there has been a change in index definition and sets the
appropriate handler flags which helps the SE to determine whether a index rebuild
needs to be performed. The 'has_index_def_changed()' did not check if the change
in length had a compatible packed data representation and marked it as a change in
index by setting the handler flags DROP_INDEX and ADD_INDEX triggering a recreation
of indexes in InnoDB.
When 'PACK_KEYS' option is not specified, indexes on columns with string types are
marked for packing through HA_PACK_KEY. Currently only MyISAM engine supports it.
Indexes on columns with length greater than 8 bytes were marked for packing
irrespective of the storage engine. Converting the indexes from non-packed to packed
i.e expanding the varchar column from lesser than 8 chars to more than 8 chars using
ALTER was marked as a change in index definition during the check in
'has_index_def_changed()' even though InnoDB does not support packed keys.
The handler API ha_innobase::max_supported_key_part_length() returned an incorrect
maximum support key part length since the row format of the table was not taken into
account. Hence creation of tables using REDUNDANT/COMPACT row format with index size
exceeding the SE limit were allowed.
Fix:
===
a) A new handler flag 'Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH"
is introduced. This is set in 'has_index_def_changed()' when the
index length differs due to column modification and has compatible
packed data representation while determining if the index definition
has changed.
b) Introduced a handlerton flag 'HTON_SUPPORTS_PACKED_KEYS' to check for
'PACK_KEYS' support which is currently set for MyISAM engine since it
is the only engine which supports packed keys. The 'HTON_SUPPORTS_PACKED_KEYS'
is checked prior to setting the index flag 'HA_BINARY_PACK_KEY' for packed keys.
Hence for InnoDB the packed key flag for indexes is not set.
c) The handler API max_supported_key_part_length() has been modified to take 'create_info'
as a parameter from which the row_format can be fetched and appropriate index limit can
be computed and returned by the InnoDB implementation of the handler API. More details
on the behavior is mentioned in the table below.
- Since the index limit is computed correctly and checked at the SQL layer,
the error message 'ER_TOO_LONG_KEY' is reported at the SQL layer instead of
'ER_INDEX_COLUMN_TOO_LONG' (which was reported by the handler interface
after mapping the error returned by SE).
- For COMPACT and REDUNDANT row format, when the index size exceeds 767 bytes,
a warning is reported in non-STRICT mode and the index is truncated to fit
767 bytes. In a STRICT mode, an error is reported.
This table describes the behavior of INDEX limit, Type of INDEX and
behavior under STRICT and NON_STRICT mode.
IL===> Index Limit.
-------------------------------------------------------------------------------|
Row Format |INDEX LIMIT | STRICT MODE(>IL) | NON-STRICT MODE(>IL) |
----------------------|--------------------------------------------------------|
Compact/Redundant | 767 bytes | Error | Index truncation(767) |
(Non Unique Index) | | | and warning. |
--------------------------------------------------------------------------------
Compact/Redundant | 767 bytes | Error | Error |
(Unique/Primary Index)| | | |
--------------------------------------------------------------------------------
Dynamic/Compressed | 3072 byes | Error | Index truncation(3072) |
(Non Unique Index) | | | and warning |
--------------------------------------------------------------------------------
Dynamic/Compressed | 3072 bytes| Error | Error |
(Unique/Primary Index)| | | |
--------------------------------------------------------------------------------
5.6 AND 5.7 DESCRIPTION =========== http://dev.mysql.com/doc/refman/5.7/en/set-password.html documents that between 5.6 and 5.7, one format of "SET PASSWORD" changes its syntax from: SET PASSWORD [for user] = [hash of password] to SET PASSWORD [for user] = [password] In cross version replication scenario when the master is in 5.6 and slave is in 5.7, the above SET PASSWORD command results in a different password hash on latter than the former. ANALYSIS ======== Note that this bug can also be reproduced when both master and slave belong to 5.7 with 'log-builtin-as-identified-by-password=ON'. In such a case SET PASSWORD statements are logged as SET PASSWORD statements, rather than being rewritten as ALTER USER statements. So when the command: SET PASSWORD [for user] = [password] is fed to slave, it is hashing the already hashed input string which results in master having hash of password and slave having double hash of password. Currently the flag 'uses_identified_by_clause' is set to false in change_password() if 'log_builtin_as_identified_by_password' is true and it's a slave thread. This flag is used in set_and_validate_user_attributes() to determine if hashing is required or not. FIX === Relaxed this criteria by removing the 1st condition. So now whenever its a slave thread (or a binlog applier thread), it can be safely assumed that the input string is hash that was already computed on master. We immediately set 'uses_authentication_string_clause' to true here so that it later avoids double hash in set_and_validate_user_attributes() The fix is restricted to 5.7 since we support cross- version replication only for two consecutive versions which in this case would be 5.6 and 5.7.
…NDOWS PROBLEM ------- This test is failing sporadically in windows because windows only supports path length of 260 characters. When we run this test with really long path and with long partition names it fails with OS error saying "too long path" . FIX --- Presently disabling this test for windows. We should enable NTFS long name feature in all pb2 machines and then enable this test for windows.
…RORS Problem ======= Replicating from older to newer MySQL server versions may lead to ER_PARSE_ERROR on replication applier threads because of, for example, the workload is creating a table using a name that on the older server version is now a reserved word. One common workaround fix for this issue DBAs/operators do is to apply the offending transaction manually (changing it enough to be applied without errors) and making the replication applier thread to skip the offending transaction already present on slaves relay log. When GTID_MODE is ON, the recommended way of making the replication applier to skip a transaction is to commit its GTID with an empty transactions (or with the replacement transaction), but GTID auto skip was not working for statements leading to ER_PARSE_ERROR. Analysis ======== GTID auto skip functionality depends on MySQL parser for: - Not skip "innocent" statements. Here, "innocent" includes SET, SHOW, SELECT, DO, USE, and empty query, unless it invokes a stored function. The reason we allow innocent statements to execute even within skipped transactions is that they can be useful for testing and debugging. E.g., we want to run SELECT @@session.gtid_owned to check that there is not a bug that makes the server acquire ownership. - Keep track of transaction boundaries. When applying a workload dumped from mysqlbinlog client program, even skipping statements from already applied transactions, the client session applying the workload must known if a statement is a DDL or a DML (if it is supposed to be wrapped with "BEGIN/COMMIT" or not). Fix === This patch will make the replication applier thread to ignore ER_PARSE_ERROR when applying query events if the transaction being applied is also being GTID auto skipped. Making workloads dumped from mysqlbinlog to also work with GTID auto skip when some statements lead to ER_PARSE_ERROR is too risk, as the GTID enforcement logic could not be guaranteed without having detailed information about the offending statement.
AN AREA SELECTED FOR UPDATE Backport fix to mysql-5.7 Reviewed-by: Allen Lai <[email protected]>
Backport fix to mysql-5.7 Reviewed-by: Allen Lai <[email protected]>
Changing the log file acquires the log-lock. If the file cannot be changed, we try to inform the user of this. To do this, we call the error logger, which in turn waits to acquire the log-lock, and thus hangs forever. With this patch, we first release the log-lock in case of an error, then try to write the message (to the old log, if any), and finally re-acquire the lock as the caller expects to have to release it.
client/mysql.cc: In function void build_completion_hash(bool, bool):
client/mysql.cc:2674:37: error: invalid conversion from char to char* [-fpermissive]
field_names[i][num_fields*2]= '\0';
^~~~
TO VARCHAR(40) INSTANTANEOUSLY Post push fix for test case failure.
Reviewed-by: Sunny Bains <[email protected]>
…PLE OF 1/10TH OF ITSELF
Analysis:
Setting binlog_group_commit_sync_no_delay_count option means that the
server exits the wait procedure if the number of sessions reaches the
count given before the timeout i.e is set in binlog_group_commit_sync_delay
elapses. In order to check if session count has reached the given limit,
the waiting time is broken into small intervals called as delta. The delta
is calculated as 1/10th of total wait time. After each delta waiting time
is elapsed queue size is checked to see if count has reached. If count
is not reached then wait time is modified
"to_wait = to_wait - delta".
This process is repeated until to_wait > 0 and count has not been reached.
delta is calculated like this
ulong delta=
DBUG_EVALUATE_IF("bgc_set_infinite_delay", 100000,
max<ulong>(1, (to_wait * 0.1)));
When to_wait which is the value of sync_delay is a non multiple of the
delta(3) like lets say 32, as this is not a multiple of to_wait time
there will be a point in the waiting code where to_wait = 2, and then
to_wait(2) = to_wait(2) - delta(3) = -1 now as to_wait is of type ulong
so the value will be wrapped and to_wait = 18446744073709551615 [ULONG_MAX].
This will make the waiting loop continue forever.
FIL_SPACE_GET(TABLE->SPACE) != __NULL] Issue ===== For a partitioned table, FLUSH TABLES .... FOR EXPORT immediately after a ALTER TABLE ... DISCARD TABLESPACE results in an assertion being hit. Fix === It should not be possible to do a flush tables for export for a file-per-table after discarding its tablespace. This is handled by throwing a ER_TABLESPACE_DISCARDED error even before we start processing the request. This was fixed for non-partitioned tables as part of fix for bug#22899690. The same fix needs to be ported for partitioned RB : 19889 Reviewed-by : Allen lai <[email protected]>
(cherry picked from commit 9e9e1129faae9d0b096a51ab3fb63ce8ed4b847b)
(cherry picked from commit b5b986b2cbd9a7848dc3f48e5c42b6d4e1e5fb22)
Replacement of the read-write lock with the lockless synchronization. Bug fixes ========= Bug#24353553 AUDIT PLUGIN UDF'S DEADLOCK SERVER WHEN TABLES ARE LOCKED Reviewed-by =========== Marc Alff <[email protected]>
Deb packaging automatically strips out debug symbols from the binaries. Debian 9 automatically generates separate dbgsym packages with the symbols, so we want to do the same for the other apt platforms.
'counter' must live longer than objects which point to it. Change-Id: Idb157a3de4f2f42194f05ad87cdee23741be2402
Problem: There are two problems: 1. If there is one secondary index on extenally stored column and another seconday index on virtual column (whose base column is not externally stored). then while updating seconday index on vitrual column, virtual column data is replaced by externally stoared column. 2. In row update operation, node->row contains shallow copy of virtual data fields. While building an update vector containing all the fields to be modified, compute virtual column. which may causes change in virtual data fields in node->row. In both the above cases, while updating seconday index on virtual column, couldn't find the row and hit an explicite assert inside ROW_NOT_FOUND. Fix: 1. Added check if column is virtual then its ext flag should be ZERO and virtual column data will not be replaced by offset column data. 2. Deep copy of virtual data fields for node->row. RB: #20382 Reviewed by : [email protected]
Problem: The "Innodb Merge Temp File" as reported in a wait which is part of an InnoDB Online Alter Table is reported as data_dir/Innodb Merge Temp File" while an "lsof +L1" during an online alter table shows that two temp files are created in @@tmpdir instead of in the @@datadir Fix: added the current path when calling PSI_FILE_CALL Follow up fix. Reviewed by by aditya <[email protected]> RB#20302
This worklog is created for the backport of the WL#11568: "Group Replication: option to shutdown server when dropping out of the group" to MySQL 5.7 On the backport to 5.7, we will keep the 5.7 existing behaviour, that is, when a failure happens the server switches to read_only mode. The DBA will be able to choose the new behaviour by adjusting the option group_replication_exit_state_action.
Provides UDFs for data masking and data generating
Description: Server may exit during SELECT on a MERGE table if concurrent INSERT SELECT statements are executing in some sequence. Analysis: Optimizer creates a clone of MRG_INFO structure of the merge table for index merge optimization during the execution of SELECT statement on a MERGE table. Due to concurrent INSERT SELECT statements, there arises a scenario where the file_offset values maintained by the two MRG_INFO structures becomes inconsistent. This in turn results in a read from an incorrect position on the child table which later results in the server crash. Fix:- Table's main MRG_INFO structure is also updated with the help of the function, 'info()' just after the clone for MRG_INFO is created [inside 'ha_myisammrg::open()']. This will make sure that all the values maintained by both the structures will be in sync during the execution.
…COMMUNITY AND COMMERCIAL Merge branch 'mysql-5.6' into mysql-5.7 (cherry picked from commit 857d132b98f69821e337063343d9ea680b719695)
Post push fix. Adding missing deep copy of virtual data fields for node->row. Disable test-case (ASAN failure: bug #28556793) (cherry picked from commit d5550ffdfda950f25bb2680d043107c777b08e94)
…ING. - Due to changes in packages, add more obsoletes to server package. (cherry picked from commit 73eafe89039069cc438ee26d9ca9a550c1ffa62b)
… SUPPORT IS NOT THERE YET - Switch openssl version to 1.0.x for fedora29 builds (cherry picked from commit c6a0229be8964f631ff5a0ce4fe849acaa32376d)
(cherry picked from commit a7114ceac42e82a8b152f3e2e183db4791ed54a2)
https://jira.percona.com/browse/PS-4709 *** Reverted orphan commit mysql/mysql-server@913071c "BUG#26848813: INDEXED COLUMN CAN'T BE CHANGED FROM VARCHAR(15) TO VARCHAR(40) INSTANTANEOUSLY" which used to be in 5.7.23 but due to 'git push --force ...' in the upstream was lost. It re-appears in 5.7.24 as mysql/mysql-server@f9064a4 "BUG#26848813: INDEXED COLUMN CAN'T BE CHANGED FROM VARCHAR(15) TO VARCHAR(40) INSTANTANEOUSLY" and mysql/mysql-server@005ef9f "Bug26848813: INDEXED COLUMN CAN'T BE CHANGED FROM VARCHAR(15) TO VARCHAR(40) INSTANTANEOUSLY".
https://jira.percona.com/browse/PS-4709 *** Reverted orphan commit mysql/mysql-server@3e38cf4 "BUG#26225783 MYSQL CRASH ON CREATE TABLE (REPRODUCEABLE) -> INNODB: A LONG SEMAPHORE WAIT" which used to be in 5.7.23 but due to 'git push --force ...' in the upstream was lost. It re-appears in 5.7.24 as mysql/mysql-server@af43dc2 "BUG#26225783 MYSQL CRASH ON CREATE TABLE (REPRODUCEABLE) -> INNODB: A LONG SEMAPHORE WAIT".
https://jira.percona.com/browse/PS-4709 *** Updated man pages from MySQL Server 5.7.24 source tarball. *** Updated 'scripts/fill_help_tables.sql' from MySQL Server 5.7.24 source tarball.
https://jira.percona.com/browse/PS-4709 *** Our fix in for PS-3937 "Some file operations in mf_iocache2.c are not instrumented" (https://jira.percona.com/browse/PS-3937) (commit b9deeac) left intact as it is identical to the upstream fix for Bug #27788907 / #90264 "Some file operations in mf_iocache2.c are not instrumented" (https://bugs.mysql.com/bug.php?id=90264) (commit mysql/mysql-server@bac287c). Only formatting changes. *** Our fix for PS-1134 "LP #1739734: Federated table returns error 1430 from storage engine" (https://jira.percona.com/browse/PS-1134) (commit 78a728f) left intact as it is identical to the upstream fix for Bug #27493633 / #89537 "Regression in FEDERATED storage engine after GCC 7 fixes" (https://bugs.mysql.com/bug.php?id=89537) (commit mysql/mysql-server@b15b4ac). Only formatting changes. *** The fix for Oracle's Bug #27799513 "POTENTIAL DOUBLE FREE OR CORRUPTION OF HEAP INFO (HP_INFO)" (commit mysql/mysql-server@22e99fc) re-applied to Percona's extended Heap Storage Engine. 'main.heap_btree' MTR test case extended with additional checks for this issue. *** Our fix for PS-4513 "Inconsistent SELECT...ORDER BY results with euckr charset / euckr_bin collation" (https://jira.percona.com/browse/PS-4513) (commit 919b2c8) left intact as it is identical to the upstream fix for Bug #28104394 / #91032 "InnoDB 5.7 Primary key scan lack data" (https://bugs.mysql.com/bug.php?id=91032) (commit mysql/mysql-server@94208bc) and Bug #91091 "Inconsistent SELECT...ORDER BY results with euckr charset / euckr_bin collation" (https://bugs.mysql.com/bug.php?id=91091). Our MTR test case 'innodb.bug91091' left as is. *** Reverted 'xdr_utils.h' part of our fix for PS-3767 "LP #1738417: Fix compilation warnings/errors with clang" (https://jira.percona.com/browse/PS-3767) (commit 320473c) in favor of the upstream fix for the Bug #28099963 / #91071 (https://bugs.mysql.com/bug.php?id=91071) (commit mysql/mysql-server@1f610f7). *** Re-recorded 'innodb.xtradb_compressed_columns_mysqldump' and 'innodb.xtradb_compressed_columns_with_dictionaries' MTR test cases because of the changed error code values. *** Re-recorded 'main.mysqlshow' MTR test case: added missing 'INNODB_TABLESPACES_SCRUBBING' into the list of known tables. This should have been done when 'scrubbing' was merged. *** Fixed and re-recorded 'main.percona_heap_blob' MTR test case because of the new warning added in the fix for the upstream Bug #27788685 / #90266 "No warning when truncating a string with data loss" (https://bugs.mysql.com/bug.php?id=90266) (commit mysql/mysql-server@1501557). *** Re-recorded 'innodb.general_ts_encrypt' and 'innodb.percona_force_encryption' MTR test cases because of the new warning introduced in WL #11571 "Deprecate Shared tablespaces in partitioned table" (commit mysql/mysql-server@e08dee47). *** Re-recorded 'main.mysqldump' MTR test case because of the rocksdb-related changes done previously. *** Added 'innodb.bug88747' MTR test case for Bug #27216817 / #88747 "InnoDB: Failing assertion: prebuilt->table->n_mysql_handles_opened == 1" fixed in 5.5.60, 5.6.40, 5.7.22, 8.0.11 (commit mysql/mysql-server@c0b4d74). Adding a unique index to an InnoDB table on which multiple locks were held could raise an assertion. *** Added 'main.bug88781' MTR test case for Bug #26881798 / #88781 "handle_fatal_signal (sig=11) in replace_db_table" fixed in 5.5.60, 5.6.40, 5.7.22, 8.0.4 (commit mysql/mysql-server@9e1035c). Dropping an index from a system table could cause a server exit. *** Added 'innodb.bug88782' MTR test case for Bug #27225649, #27229072 / #88782 "Failing assertion: prebuilt->sql_stat_start || prebuilt->select_lock_type != LOC" fixed in 5.5.60, 5.6.40, 5.7.22, 8.0.11 (commit mysql/mysql-server@ddaf0f1). InnoDB: A REPLACE operation on a temporary table raised an assertion. *** Added 'main.bug88800' MTR test case for Bug #27230925 / #88800 "handle_fatal_signal (sig=11) in show_routine_grants" fixed in 5.5.61, 5.6.41, 5.7.23, 8.0.12 (commit mysql/mysql-server@6d570d7). Mishandling of internal privilege structures could cause a server exit. *** Added 'main.bug83739' MTR test case for Bug #25062396 / #83739 "Assertion `cur_shape != Gcalc_function::shape_point' failed." fixed in 5.6.39, 5.7.21, 8.0.4 (commit mysql/mysql-server@b5323d156da) (commit mysql/mysql-server@180adbe271e). For geometry calculations, invalid input parameters could lead to an incorrect result buffer and cause an assertion to be raised or a server exit. *** Added 'innodb.bug79821' MTR test case for Bug #22486025 / #79821 "InnoDB: Failing assertion: key_len != 0 || find_flag != HA_READ_KEY_EXACT" fixed in 5.7.21, 8.0.4 (commit mysql/mysql-server@1a13f7f) A "wrong key column" error was added to address an unsupported index creation scenario. *** VERSION raised to "5.7.24-26". univ.i version raised to "26". *** This merge also fixes PS-1017 "LP #1631816: slave replication breaks after bug #74145 happens in master" (https://jira.percona.com/browse/PS-1017) as corresponding upstream Bug #24786290 / #83232 "replication breaks after bug #74145 happens in master" (https://bugs.mysql.com/bug.php?id=83232) was fixed in 5.7.24 (commit mysql/mysql-server@4a3761a) (commit mysql/mysql-server@093c654). Replication: When FLUSH statements for specific log types (such as FLUSH SLOW LOGS) resulted in an error, the statements were still written to the binary log. This stopped replication because the error had occurred on the master, but did not occur on the slave. MySQL Server now checks on the outcome of these FLUSH statements, and if an error occurred, the statement is not written to the binary log.
https://jira.percona.com/browse/PS-4709 Reverted mysql/mysql-server@e93e8db "Bug#28505638 REWRITE INNODB TESTS TO IGNORE EXPECTED ASAN ERRORS" because it just suppresses ASan errors instead of fixing them. See Bug #93164 "Memory leak in innochecksum utility detected by ASan" (https://bugs.mysql.com/bug.php?id=93164), Bug #93165 "Memory leak in sync_latch_meta_init() after mysqld shutdown detected by ASan" (https://bugs.mysql.com/bug.php?id=93165) and Bug #92131 "ASan: Direct leak of 272 byte(s) in main.mysqlpump_partial_bkp MTR test case" (https://bugs.mysql.com/bug.php?id=92131).
|
Jenkins build link (--big-test) |
laurynas-biveinis
approved these changes
Nov 28, 2018
|
Created https://jira.percona.com/browse/PS-5561 followup |
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://jira.percona.com/browse/PS-4709