| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem was in such scenatio:
T1 - starts geristering query and locked QC
T2 - starts disabling QC and wait for UNLOCK
T1 - unlock QC
T2 - disable QC and destroy sugnals without waitiung for query unlock
T1 a) - not yet unlocked query in qc and crach on attempt to unlock because QC signals are destroyed
b) if above was done before distruction, it execute end_of results first time
it exit on after try_lock which see QC disables and return TRUE.
But it do not reset query_cache_tls->first_query_block which lead to
second call of end_of_result when diagnostic arena has already inapropriate staus (not is_eof()).
Fix is:
1) wait for all queries unlocked before destroing them by locking and unlockin
2) remove query_cache_tls->first_query_block if QC disabled
|
| |
|
|
| |
Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>
|
| | |
|
| |
|
|
|
| |
Fix the call to correspond protocoll of pagecache call.
Fix of misleading variables names.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug happens when locking the same Aria "transactional" table
(page format) more then once with LOCK TABLES and inserting into one
of them with INSERT ... SELECT when the table is empty.
Fixed by ensuring we don't use fast bulk insert if table is opened
twice with LOCK TABLES (as this changes table->s->state)
Code changes:
- Added use_count to MARIA_USED_TABLES to be able to check if
table is opened twice for a statement/lock table
- Don't clear history or reset info->start_state if we
don't have versioning. One reason for the bug was
was that info->start_state was set to point to different
states for the two tables. If there is no versioning
info->start_state should always point to info->s->state.common.
Other things:
- Fixed also some typos that was noticed while scanning the code
- More DBUG_PRINT
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
list"
The warning was originally added in
commit c67663054a7db1c77dd1dbc85b63595667a53500
(MySQL 4.1.12, 5.0.3) to trace claimed undo log corruption that
was analyzed in https://lists.mysql.com/mysql/176250
on November 9, 2004.
Originally, the limit was 20,000 undo log headers or transactions,
but in commit 9d6d1902e091c868bb288e0ccf9f975ccb474db9
in MySQL 5.5.11 it was increased to 2,000,000.
The message can be triggered when the progress of purge is prevented
by a long-running transaction (or just an idle transaction whose
read view was started a long time ago), by running many transactions
that UPDATE or DELETE some records, then starting another transaction
with a read view, and finally by executing more than 2,000,000
transactions that UPDATE or DELETE records in InnoDB tables. Finally,
when the oldest long-running transaction is completed, purge would
run up to the next-oldest transaction, and there would still be more
than 2,000,000 transactions to purge.
Because the message can be triggered when the database is obviously
not corrupted, it should be removed. Heavy users of InnoDB should be
monitoring the "History list length" in SHOW ENGINE INNODB STATUS;
there is no need to spam the error log.
|
| |
|
|
| |
Roll back to most general duplicate removing strategi in case of different stratagies for one position.
|
| |
|
|
|
| |
Backport the fix from 10.0.33 to 5.5, in case someone compiles XtraDB
with -DUNIV_LOG_ARCHIVE
|
| |
|
|
|
|
|
|
|
| |
The XtraDB option innodb_track_changed_pages causes
the function log_group_read_log_seg() to be invoked
even when recv_sys==NULL, leading to the SIGSEGV.
This regression was caused by
MDEV-11027 InnoDB log recovery is too noisy
|
| | |
|
| |
|
|
|
|
|
|
| |
trx_undo_rec_get_partial_row(): When the PRIMARY KEY includes a
column prefix of an externally stored column, the already parsed
part of the undo log record may contain a reference to
an off-page column. This is the case in the bug58912 test in
innodb.innodb.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
from secondary indexes
This is a regression caused by MDEV-14051 'Undo log record is too big.'
Purge in the secondary index is wrongly skipped in
row_purge_upd_exist_or_extern() because node->row only does not contain all
indexed columns.
trx_undo_rec_get_partial_row(): Add the parameter for node->update
so that the updated columns will be copied from the initial part
of the undo log record.
|
| |
|
|
|
|
|
|
|
|
|
| |
installation
* don't use Env module in tests, use $ENV{xxx} instead
* collateral changes:
** $file in the error message was unset
** $file in the other error message was unset too :)
** source file arguments are conventionally upper-cased
** abort the test (die) on error, don't just echo/exit
|
| |
|
|
|
|
|
| |
If translation table present when we materialize the derived table then
change it to point to the materialized table.
Added debug info to see really what happens with what derived.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
my_fill_8bit / filesort
In the function make_sortkey a tmp buffer was defined and in the absence of
param->tmp_buffer, tmp buffer used the sort_keys buffer. sort_keys buffer
has a length defined in sort_field->length, while param->tmp_buffer is
stored in param->rec_length. Make sure to use the appropriate length
based on which buffer we are using otherwise we'll overflow.
Also added a type cast to size_t during the calculation of the sort keys
buffer size to avoid an oveflow if the buffer size exceeds 32 bits.
|
| | |
|
| |
|
|
| |
Correctly print separator string in single quotes.
|
| | |
|
| |
|
|
|
|
|
|
| |
This reverts commit 7603463a46b288c1b5630348e36c622e4c2abb09.
The commit itself is fine, however when disabling volatile, compiler
optimizations mess up our double results due to precision differences.
Revert the patch till a proper solution is found.
|
| |
|
|
|
|
|
| |
This was added in c79641594348 but would hurt all other compilers
because of Visual Studio. Hopefully this has been fixed now.
Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
| |
BIT fields
For BIT field null_bit is not set to 0 even for a field defined as NOT NULL.
So now in the function TABLE::create_key_part_by_field, if the bit field is not nullable
then the null_bit is explicitly set to 0
|
| | |
|
| |
|
|
| |
MariaDB adjustments to test case innodb-replace-debug.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Imported missing test case from MySQL 5.7 for
commit 25781c154396dbbc21023786aa3be070057d6999
Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
Date: Mon Feb 24 14:00:03 2014 +0530
Bug #17604730 ASSERTION: *CURSOR->INDEX->NAME == TEMP_INDEX_PREFIX
MariaDB 5.5 does not seem to be affected.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uses alias in HAVING when sql_mode = 'ONLY_FULL_GROUP_BY'
This patch corrects the patch for bug#18739: non-standard
HAVING extension was allowed in strict ANSI sql mode
added in 2006 by commit 4b7c4cd27f68b9aac1970b9f21c50d4eee35df7d.
As a result of incompleteness of the fix in the above commit
if a query with GROUP BY contained an aggregate function with an
alias and this alias was used in the HAVING clause of the query
the server reported an error when sql_mode was set to
'ONLY_FULL_GROUP_BY'.
|
| |
|
|
|
| |
don't close stdout/stderr, redirect them to /dev/null instead.
otherwise redirections like >&2 fail with "invalid file descriptor"
|
| |
|
|
|
|
|
| |
present.
thread_pool_server_audit.test fixed.
plugin version updated.
|
| |
|
|
|
|
|
| |
present.
Escape special characters (like \r \n \t) instead of
replacing them with spaces.
|
| |
|
|
|
| |
Replace all references in InnoDB and XtraDB error log messages
to bugs.mysql.com with references to https://jira.mariadb.org/.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
range of string lengths
InnoDB was writing unnecessary information to the
update undo log records. Most notably, if an indexed column is updated,
the old value of the column would be logged twice: first as part of
the update vector, and then another time because it is an indexed column.
Because the InnoDB undo log record must fit in a single page,
this would cause unnecessary failure of certain updates.
Even after this fix, InnoDB still seems to be unnecessarily logging
indexed column values for non-updated columns. It seems that non-updated
secondary index columns only need to be logged when a PRIMARY KEY
column is updated. To reduce risk, we are not fixing this remaining flaw
in GA versions.
trx_undo_page_report_modify(): Log updated indexed columns only once.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NAME_CONST('NAME', NULL))
based on:
commit f7316aa0c9a
Author: Ajo Robert <ajo.robert@oracle.com>
Date: Thu Aug 24 17:03:21 2017 +0530
Bug#26361149 MYSQL SERVER CRASHES AT: COL IN(IFNULL(CONST,
COL), NAME_CONST('NAME', NULL))
Backport of Bug#19143243 fix.
NAME_CONST item can return NULL_ITEM type in case of incorrect arguments.
NULL_ITEM has special processing in Item_func_in function.
In Item_func_in::fix_length_and_dec an array of possible comparators is
created. Since NAME_CONST function has NULL_ITEM type, corresponding
array element is empty. Then NAME_CONST is wrapped to ITEM_CACHE.
ITEM_CACHE can not return proper type(NULL_ITEM) in Item_func_in::val_int(),
so the NULL_ITEM is attempted compared with an empty comparator.
The fix is to disable the caching of Item_name_const item.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DESCRIPTION:
===========
The bug is related to incorrect parsing of SQL queries
when typed in on the CLI. The incorrect parsing can
result in unexpected results.
ANALYSIS:
========
The scenarios mainly happens for identifier names
with a typical combination of backslashes and backticks.
The incorrect parsing can either result in executing
additional queries or can result in query truncation.
This can impact mysqldump as well.
FIX:
===
The fix makes sure that such identifier names are
correctly parsed and a proper query is sent to the
server for execution.
(cherry picked from commit 31a372aa1c2b93dc75267d1f05a7f7fca6080dc0)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
COL), NAME_CONST('NAME', NULL))
Backport of Bug#19143243 fix.
NAME_CONST item can return NULL_ITEM type in case of incorrect arguments.
NULL_ITEM has special processing in Item_func_in function.
In Item_func_in::fix_length_and_dec an array of possible comparators is
created. Since NAME_CONST function has NULL_ITEM type, corresponding
array element is empty. Then NAME_CONST is wrapped to ITEM_CACHE.
ITEM_CACHE can not return proper type(NULL_ITEM) in Item_func_in::val_int(),
so the NULL_ITEM is attempted compared with an empty comparator.
The fix is to disable the caching of Item_name_const item.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
LAST BYTE ONLY (YASSL)
Description:- TLS cipher negociation happens incorrectly
leading to the use of a different
Analysis:- YaSSL based MySQL server will compare only the
last byte of each cipher sent in the Client Hello message.
This can cause TLS connections to fail, due to the server
picking a cipher which the client doesn't actually support.
Fix:- A fix for detecting cipher suites with non leading
zeros is included as YaSSL only supports cipher suites with
leading zeros.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Analysis
========
CREATE TABLE of InnoDB table with a partition name
which exceeds the path limit can cause the server
to exit.
During the preparation of the partition name,
there was no check to identify whether the complete
path name for partition exceeds the max supported
path length, causing the server to exit during
subsequent processing.
Fix
===
During the preparation of partition name, check and report
an error if the partition path name exceeds the maximum path
name limit.
This is a 5.5 patch.
|
| | |
| |
| |
| |
| |
| |
| | |
-STRINGS/CTYPE-UTF8.C:5151)
Backport from 5.7 to 5.5 Field_set::val_str()
should return String("", 0, cs) rather than String(NULL, 0, cs)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem & Analysis: Slave's Receiver thread, Applier thread and worker
threads are created with LOCAL-INFILE option enabled. As the document
says https://dev.mysql.com/doc/refman/5.7/en/load-data-local.html,
there are some issues if a thread enables local infile.
This flag should be enabled with care. But for the above mentioned
internal threads, server is enabling it at the time of creation.
Fix: Further analysis on the code shows that none of threads really
need this flag to be enabled at any time as Slave never executes
"LOAD DATA LOCAL INFILE" after reading it from Relay log.
Applier thread removes "LOCAL" before start executing the query.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Issue:
------
Running MTR with the --no-reorder option by specifying test cases on the
command line, without prefixing the suite name results in an error saying the
test case was not found in the main suite. This is because MTR looks for the
test case only in the main suite, and no other suites.
Fix:
----
The fix involves searching for the test in every suite if only the test name
is specified. This back-ports two bug fixes: Bug#24967869 and Bug#24365783
Reviewed-by: Pavan Naik <pavan.naik@oracle.com>
RB: 16812
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
POSSIBLE
- Add mysqlcheck tool to docker rpms for upgrade
|
| | | |
| | |
| | |
| | | |
Corrected the revert.
|
| | | |
| | |
| | |
| | | |
Temporary revert of the VS2008 redist check.
|
| | | |
| | |
| | |
| | | |
Fixed generated mysql_server.wxs not to contain duplicates, or too long ids
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Partition wasn't setting HA_OPTION_PACK_RECORD on ALTER TABLE
if the row format was PAGE.
(so one bit in the null bitmap was reserved for a deleted bit -
see make_empty_rec - and all actual null bits were one off)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
option
if it's a DROP TABLE, we cannot detect whether a table is
temporary by looking in thd->temporary_tables - because the
table might simply not exist at all.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
backport ce6c0e584e3
MDEV-8960: Can't refer the same column twice in one ALTER TABLE
Problem was that if column was created in alter table when
it was refered again it was not tried to find from list
of current columns.
mysql_prepare_alter_table:
There is two cases
(1) If alter table adds a new column and then later alter
changes the field definition, there was no check from
list of new columns, instead an incorrect error was given.
(2) If alter table adds a new column and then later alter
changes the default, there was no check from list of
new columns, instead an incorrect error was given.
|
