PS-7012: Merge MySQL 5.6.49 part 2 #3938
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
Approved-by: Bjorn Munch <[email protected]>
TABLES ON THE SAME SERVER Analysis ======== A user was able to access I_S.FILES information without having appropriate privilege. Access privilege check was missing while accessing the information_schema.FILES table. Fix === Check for PROCESS privilege for accessing INFORMATION_SCHEMA.FILES Change-Id: I010f0703febdd63fd7d118f2d2ebb2a7cdd74988
Add suppressions for -Wdeprecated-copy so that we can build with gcc9/gcc10 Also adds one suppresion for -Wdeprecated-declarations Change-Id: Ib452071a9f37808bbf384b4e1f5d4c834fd8fd37
SQL/SQL_LEX.H Problem: Removal of a subquery having a "group by" operation, which is used by an outer select results in server exit. In a query, the "group by" subquery can be considered redundant and removed assuming as there are no aggregate functions. But if the subquery is used by the outer context, it should not be removed. Fix: Do not remove the subquery if it is needed for the select list. Change-Id: I696461cb59734984fd7f7095be161999461470e1
MEMORY TABLE
Bug#25681518: CLEANUP PROCEDURE FOR MEMORY ENGINE TABLES
BREAKS GTID REPLICA
Analysis: Memory table's data will be lost after server
restarts. To keep the data consistency between master and
slave, it just binlogs an implicit DELETE statement when
the memory table is locked first time.
When the above scenario happens in a replication thread,
the server raises an assertion. The reason is that the
implicit DELETE statement consumes the GTID of the actual
transaction (the one that is stored in the relay log), so
that the the actual transaction, which comes later, has no
GTID to use. This causes the assertion.
Fix: This issue is fixed by creating a new THD object for
handling the implicit binary logging of DELETE statement.
This ensures that the implicit DELETE as well as the actual
trasaction which triggered the implicit DELETE gets binary
logged with the correct GTIDs. This fix also ensures that
the implicit DELETE will be binlogged separately and will
be wrapped by BEGIN/COMMIT pair.
RB#24351
…H A COMPOSITE PREFIX INDEX
Description:
The SELECT query with order-by clause gives unordered results if following
conditions are met:
1. It should be a partitioned table with a composite prefix index.
2. WHERE clause should have an equality condition on the prefixed column.
3. Prefix column in index should be leading key.
4. Column used in ORDER-BY clause should be trailing key in the index.
5. Index should be chosen for handling for ORDER-BY clause.
Ex: SELECT * FROM table WHERE prefixed_index_column = "constant" and order by
"next_column_after_prefixed_index_column"
ANALYSIS:
While checking if an index could be used for sorting, optimizer picks an index
if all the columns in the index before the ordering columns are constants for
the execution (have equality conditions in the where clause). However this is
not right when the columns are prefixed and the table is partitioned.
To understand it better let's take following DDL:
CREATE TABLE table( col1 int NOT NULL,
col2 varchar(2) DEFAULT NULL,
KEY col2_idx (data(1),id)
) DEFAULT CHARSET=utf8
/*!50100 PARTITION BY RANGE (id)
(PARTITION p10 VALUES LESS THAN (10) ,
PARTITION p20 VALUES LESS THAN (20) ) */;
Lets assume after inserting in table we have(records is in sorted order of
partition column)
partition p10 contains (4, 'ab'), (5, 'ab'), (5, 'ac'), (6, 'ab') and
partition p20 contains (14, 'ab'), (15, 'ab'), (15, 'aa'), (16, 'ab')
Now let's take following query for execution
SELECT col1 FROM tutf8 WHERE col2 = 'ab' ORDER BY col1 ASC;
In this query we have ORDER BY clause on 'col2' but the index is on 'col2' and
'col1'. So it is sorted accordingly. The first row to be out from both the
partitions is "4", followed by "5" as they are lesser than "14". After this it
will compare between ('ac', 5) and ('ab', 14). It will return 14 as
'ab' < 'ac'. The active partition now becomes p20. This will give out 15, 16
as 'ab', 'aa' are lesser than 'ac'. This will leave us with the final value
which is 6.
Hence final result of the query will be
+----+
|col1|
+----+
| 4 |
| 5 |
| 14 |
| 15 |
| 16 |
| 6 |
+----+
SOLUTION:
test_if_order_by_key() calls new function is_prefix_index to determine whether
prefix index is being used for sorting. If it is true, optimizer does not pick
this index for ordering.
Change-Id: I2715867ca3db537ba47ed82bf44a3f4e65949465
MEMORY TABLE
Bug#25681518: CLEANUP PROCEDURE FOR MEMORY ENGINE TABLES
BREAKS GTID REPLICA
Post push patch to fix valgrind test failure in 5.6 and
doxygen build failure in 8.0 and trunk.
RB#24351
Legacy referenced to tcmalloc are removed. Change-Id: Ifc691265d38a2b0665655f7532d1cab9fa768d18
DESCRIPTION =========== There is a memcpy-param-overlap (likely leading to a multi byte write heap buffer overflow) in function cli_read_rows called by mysql_store_result. FIX === Added appropriate boundary checks while reading the packets, and if an invalid packet data is detected, an error is returned. RB: 24485
https://jira.percona.com/browse/PS-7012 *** Updated man pages from MySQL Server 5.6.49 source tarball. *** Updated 'scripts/fill_help_tables.sql' from MySQL Server 5.6.49 source tarball.
oleksandr-kachan
force-pushed
the
merge-mysql-5.6.49-part2
branch
from
936c28c to
4b6fe1e
Compare
…olved) https://jira.percona.com/browse/PS-7012 *** VERSION raised to "5.6.49-89.0". PERCONA_INNODB_VERSION in univ.i raised to "89.0". *** Add config for rpl.rpl_gtid_delete_memory_table_after_start_server test to enable gtid-mode. *** Remove tcmalloc support from percona-server.spec. *** Updated result file for rpl.rpl_mdev382 test. *** Fix from github.com/mysql/mysql-server/commit/6188a828cd413fd9f09d3488be4b6dde6d781657 brakes code in case WITH_PARTITION_STORAGE_ENGINE is disabled. Added checkup for WITH_PARTITION_STORAGE_ENGINE around corresponding code in sql_select.cc.
oleksandr-kachan
force-pushed
the
merge-mysql-5.6.49-part2
branch
from
4b6fe1e to
1a8fb71
Compare
Approved By: Erlend Dahl <[email protected]>
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-7012
Updated man pages from MySQL Server 5.6.49 source tarball.
Updated 'scripts/fill_help_tables.sql' from MySQL Server 5.6.49 source tarball.
VERSION raised to "5.6.49-89.0".
PERCONA_INNODB_VERSION in univ.i raised to "89.0".
Add config for rpl.rpl_gtid_delete_memory_table_after_start_server
test to enable gtid-mode.
Remove tcmalloc support from percona-server.spec.
Updated result file for rpl.rpl_mdev382 test.
Fix from github.com/mysql/mysql-server/commit/6188a828cd413fd9f09d3488be4b6dde6d781657
brakes code in case WITH_PARTITION_STORAGE_ENGINE is disabled.
Added checkup for WITH_PARTITION_STORAGE_ENGINE around corresponding
code in sql_select.cc.