Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PS-7200: Merge MySQL 5.6.50 part 1 (up to e453966634c2834c0886e0e3866e6e13c6cee00e) #4096

Merged

Conversation

oleksandr-kachan
Copy link
Contributor

VERSION raised to "5.6.50-90.0".
PERCONA_INNODB_VERSION in univ.i raised to "90.0".

bkandasa and others added 16 commits June 1, 2020 08:06
Approved By: Erlend Dahl <[email protected]>
The problem was that LOCK TABLES statement on a view did insufficient
privilege checking for view's underlying tables.

This patch solves the problem by ensuring that when we lock tables
through a view we require the same SELECT and LOCK TABLES privileges
on its underlying tables as would have been required if these tables
were locked directly.

To avoid breaking mysqldump/pump tools which need to be able to dump
views with broken definer, which in default mode involves locking of
such views, we accept both cases when:
1) User whose context will be used for view execution has necessary
   privileges on underlying tables.
2) User who originally inititated LOCK TABLES operation has them
   (which is typically for admin/backup users used for dumping).

This is version of the patch for 5.6 branch.

Reviewed-by: Sivert Sorumgaard <[email protected]>
Reviewed-by: Gopal Shankar <[email protected]>
Issue
=====
We make use of prebuilt->m_end_range flag to check if end_range condition is
not satisfied if the number of uncommitted rows we've passed during the scan
is > 100 to avoid full table traversal. In the call to row_search_mvcc if we
see that the flag is set we unset it and immediately return indicating that
there are no more row to be fetched for the the given range.

This is benefecial if we have prefetched rows that we need to return to the
server. In such a case, every time the server calls row_search_mvcc, after
fetching the first row, if there are any cached rows we return the cached
row, and when we've returned all the cached rows we check if the end_range
flag is set and if it's we unset it and return.

Turns out that this flag is not reset at the beginning of every index read
resulting in some reads being aborted because of this and resulting in
missing rows. One such case is when optimiser decides to use
Multi-Range-Read (MRR) optimisation as the range query specified by the
user is split into multiple range queries.

Fix
===
In row_search_mvv() reset the prebuilt->m_end_range cache at the start of
every index read.

RB: 24201
Reviewed-by: Debarun Bannerjee <[email protected]>
Description: Some of the certificates used for testing
             CRL support are expired. This caused various
             tests to failed.

Fix: - Added new set of certificates
     - Updated read-me for CRL generation

RB: 24714
…ORT_LENGT SET

Description:
Assertion fialure for a query with ORDER By clause when server is
started with SORT_BUFFER_SIZE = 1125899906842624 and MAX_SORT_LENGTH
SET is set.

ANALYSIS:
If SORT_BUFFER_SIZE and MAX_SORT_LENGTH SET is set with some value
because of which variable Sort_param.max_keys_per_buffer in
filesort() can get value '0' then it asserts at statement
"n < m_size" in "Bounds_checked_array<unsigned char*>::operator[]".
So reason for this is we allow to create sort buffer of size '0' but
we assert when it's size is '0'.

SOLUTION:
Changed the following statement in filesort().

-     if (table_sort.get_sort_keys())
+      if (table_sort.sort_buffer_size() > 0 && table_sort.get_sort_keys())

This change will ensure we continue to search and allocate the sort
buffer if it's value is not greater than '0'.

Change-Id: I87d6a19839a7476d09aca49b69e6a3feefdd8bde
              ROW_MYSQL_WHOLE_ROW" IN ROW0MYSQL.CC

ANALYSIS:
=========
Statements which called two stored routines, one of which
tried to create temporary table in InnoDB SE and then to
modify it and another routine simply read from the same
table, resulted in assertion failure when statement or mixed
binary log format were used.

The assertion has been triggered because SQL-layer passed to
InnoDB SE incorrect information about the operation type on
the temporary table in such cases.

The underlying issue lies in building the prelocking list in
such cases. The presence of CREATE TEMPORARY TABLE inside
the first of routines makes the server think that the table might
not exist thus it does not add it to the prelocking list in
this case. OTOH the usage of the same table in another
routine causes its addition to prelocking list with a lock
type indicating read access.

As a result, at prelocking stage we only see one table instance
in prelocking list which is marked as to be read. We pass
this information to SE by calling handler::store_lock()/
external_lock() as a side-effect of calling
mysql_lock_tables()). Later, when we try to access the same
table for modification from the first of routines, InnoDB
considers this as breach of contract and asserts. (The
actual assertion is about whether the whole row is to be
used for the operation or not and thus masked when
--binlog_format=row as we have to use the whole row in this
case anyway).

FIX:
====
Do not call handler::store_lock()/external_lock() for the
temporary tables in the extended prelocking list during
prelocking stage. Delay informing SE about operation being
perfomed (by calling handler::start_stmt()) till the point
when the table is accessed during the execution of
substatements.

Approved by:
Dmitry Lenev ([email protected])
Sivert Sorumgaard ([email protected])

Change-Id: I029f45662678f9fc5150f1ee2c7db33a11a59b67
Code used std::string without including <string>,
and this broke the build on mac.

Change-Id: Ib0acbbf38e3b2e57225bf192adf313bf1c9b6a8e
Issue:

The string functions 'concat' and 'concat_ws' return a default
String(with null data pointer) when they have to return empty
string. This propagates as a NULL value in the result.

Fix:

Return a empty String("") for empty results from the string functions
'concat' and 'concat_ws'.

Change-Id: I81a15f31b84cbad68796e96db80d6aae2d3ae0e5
…ACK()

Backport the fix for bug #29948029 (ASSERTION FAILURE IN
__GNU_CXX::NEW_ALLOCATOR() AT EXT/NEW_ALLOCATOR.H) to 5.6 and 5.7.

Change-Id: I1397de18a1932724facd1a974c56cbada25b9b25
TO TERMINATE SERVER.

Problem:
Using a large amount of nested sub-expressions in boolean full-text
search (FTS) can cause a crash.

Analysis:
For each nested sub-expression, we call fts_ast_visit_sub_exp().
which is called recursively until it reaches to the last
sub-expression.
when we use large number of nested sub-expression in FTS. Because of
undefined base condition, recursive calls to fts_ast_visit_sub_exp()
aborts the server with stack overflow error.

Fix:
Added a limit on number of nested arguments should be allowed in
fulltext search.

RB: 23443
Reviewed by : Rahul Agarkar <[email protected]>
              TRANS_SAVEPOINT

ANALYSIS:
=========
During Bootstrap, while executing the statements from sql
file passed to the init-file server option, transaction
mem_root was being freed for every statement. This creates
an issue with multi statement transactions especially when a
statement in the transaction has to access the memory used
by the previous statement in the transaction.

FIX:
====
Transaction mem_root is freed whenever a transaction is
committed or rolled-back. Hence explicitly freeing it is not
necessary in the bootstrap implementation.

Change-Id: I40f71d49781bf7ad32d474bb176bd6060c9377dc
https://jira.percona.com/browse/PS-7200
***
Updated man pages from MySQL Server 5.6.50 source tarball.
***
Updated 'scripts/fill_help_tables.sql' from MySQL Server 5.6.50 source tarball.
…olved)

https://jira.percona.com/browse/PS-7200
***
VERSION raised to "5.6.50-90.0".
PERCONA_INNODB_VERSION in univ.i raised to "90.0".
@oleksandr-kachan oleksandr-kachan changed the title PS-7200: Merge MySQL 5.6.50 part1 (up to e453966634c2834c0886e0e3866e6e13c6cee00e) PS-7200: Merge MySQL 5.6.50 part 1 (up to e453966634c2834c0886e0e3866e6e13c6cee00e) Oct 21, 2020
Copy link
Collaborator

@percona-ysorokin percona-ysorokin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@oleksandr-kachan oleksandr-kachan merged commit 9e8f26d into percona:5.6 Oct 26, 2020
@oleksandr-kachan oleksandr-kachan deleted the merge-mysql-5.6.50-part1 branch October 26, 2020 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants