-
Notifications
You must be signed in to change notification settings - Fork 481
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
oleksandr-kachan
merged 16 commits into
percona:5.6
from
oleksandr-kachan:merge-mysql-5.6.50-part1
Oct 26, 2020
Merged
PS-7200: Merge MySQL 5.6.50 part 1 (up to e453966634c2834c0886e0e3866e6e13c6cee00e) #4096
oleksandr-kachan
merged 16 commits into
percona:5.6
from
oleksandr-kachan:merge-mysql-5.6.50-part1
Oct 26, 2020
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: Erlend Dahl <[email protected]>
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
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
percona-ysorokin
approved these changes
Oct 26, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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.
VERSION raised to "5.6.50-90.0".
PERCONA_INNODB_VERSION in univ.i raised to "90.0".