WHERE and GROUP BY clause
Loose index scan may use range conditions on the argument of
the MIN/MAX aggregate functions to find the beginning/end of
the interval that satisfies the range conditions in a single go.
These range conditions may have open or closed minimum/maximum
values. When the comparison returns 0 (equal) the code should
check the type of the min/max values of the current interval
and accept or reject the row based on whether the limit is
open or not.
There was a wrong composite condition on checking this and it was
not working in all cases.
Fixed by simplifying the conditions and reversing the logic.
Merge the test case from 5.0 to 5.1 for BUG#40565
Detailed revision comments:
r5233 | marko | 2009-06-03 15:12:44 +0300 (Wed, 03 Jun 2009) | 11 lines
branches/5.1: Merge the test case from r5232 from branches/5.0:
------------------------------------------------------------------------
r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines
branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565
(Update Query Results in "1 Row Affected" But Should Be "Zero Rows").
Also, add a test case for Bug #40565.
rb://128 approved by Heikki Tuuri
------------------------------------------------------------------------
This patch changes the following defaults:
max_dirty_pages_pct: default from 90 to 75. max allowed from 100 to 99
additional_mem_pool_size: default from 1 to 8 MB
buffer_pool_size: default from 8 to 128 MB
log_buffer_size: default from 1 to 8 MB
read_io_threads/write_io_threads: default from 1 to 4
The log file sizes are untouched because of upgrade issues
Reviewed by: Heikki
the mysql test suite.
Tests removed:
1. innodb_trx_weight.test
2. innodb_bug35220.test
Include files removed:
1. have_innodb.inc
2. ctype_innodb_like.inc
3. innodb_trx_weight.inc
Also add the missing opt file for the test innodb-use-sys-malloc.test
Created a test suite 'innodb' under mysql-test/suite/innodb for the innodb plugin tests.
test suite 'innodb' has tests only which are not under any other mysql-test suites.
Total 14 testcases are added to the test suite.
Note: the patches in storage/innodb_plugin/mysql-test/patches are not applied yet
Range analysis did not request sorted output from the storage engine,
which cause partitioned handlers to process one partition at a time
while reading key prefixes in ascending order, causing values to be
missed. Fixed by always requesting sorted order during range analysis.
This fix is introduced in 6.0 by the fix for bug no 41136.
This test uses SHOW STATUS and the like, which may be unstable in the face
of logging to table, since the CSV handler is actively executing operations
and thus incrementing the counters.
Fixed by disabling logging to table for the duration of the test and restoring
it afterwards. This causes various counters to properly start counting from zero
and never advance due to CSV operations.
memory issue ?
The mysql command line client could misinterpret some character
sequences as commands under some circumstances.
The upper limit for internal readline buffer was raised to 1 GB
(the same as for server's max_allowed_packet) so that any input
line is processed by add_line() as a whole rather than in
chunks.
mysqlbinlog --database parameter was being ignored when processing
row events. As such no event filtering would take place.
This patch addresses this by deploying a call to shall_skip_database
when table_map_events are handled (as these contain also the name of
the database). All other rows events referencing the table id for the
filtered map event, will also be skipped.
uninitialized variable used as subscript
Grouping select from a "constant" InnoDB table (a table
of a single row) joined with other tables caused a crash.
The problem is that when a optimization of read-only transactions
(bypass 2-phase commit) was implemented, it removed the code that
reseted the XID once a transaction wasn't active anymore:
sql/sql_parse.cc:
- bzero(&thd->transaction.stmt, sizeof(thd->transaction.stmt));
- if (!thd->active_transaction())
- thd->transaction.xid_state.xid.null();
+ thd->transaction.stmt.reset();
This mostly worked fine as the transaction commit and rollback
functions (in handler.cc) reset the XID once the transaction is
ended. But those functions wouldn't reset the XID in case of
a empty transaction, leading to a assertion when a new starting
a new XA transaction.
The solution is to ensure that the XID state is reset when empty
transactions are ended (by either commit or rollback). This is
achieved by reorganizing the code so that the transaction cleanup
routine is invoked whenever a transaction is ended.
the thread->mysys_var parameter should be empty for the idle
embedded-server threads so that working threads can safely free
this memory.
per-file comments:
libmysqld/lib_sql.cc
Bug#43733 Select on processlist let the embedded server crash (concurrent_innodb_safelog)
set thread->mysys_var= 0 after the query is handled
mysql-test/include/concurrent.inc
Bug#43733 Select on processlist let the embedded server crash (concurrent_innodb_safelog)
enable these for the embedded-server mode
sql/sql_show.cc
Bug#43733 Select on processlist let the embedded server crash (concurrent_innodb_safelog)
show thread lock status in the query result
Problem:
Crash happened with a user-defined utf8 collation,
on attempt to insert a value longer than the column
to store.
Reason:
The "ctype" member was not initialized (NULL) when
allocating a user-defined utf8 collation, so an attempt
to call my_ctype(cs, *str) to check if we loose any important
data when truncating the value made the server crash.
Fix:
Initializing tge "ctype" member to a proper value.
mysql-test/r/ctype_ldml.result
Adding tests
mysql-test/t/ctype_ldml.test
Adding tests
strings/ctype-uca.c
Adding initialization of "ctype" member.
modified:
mysql-test/r/ctype_ldml.result
mysql-test/t/ctype_ldml.test
strings/ctype-uca.c
The crash happens because of uninitialized
lex->ssl_cipher, lex->x509_subject, lex->x509_issuer variables.
The fix is to add initialization of these variables for
stored procedures&functions.
the bug fix we would assert on missing autoinc columns. With this fix we allow
MySQL to open the table but set the next autoinc value for the column to the
MAX value. This effectively disables the next value generation. INSERTs will
fail with a generic AUTOINC failure. However, the user should be able to
read/dump the table, set the column values explicitly, use ALTER TABLE to
set the next autoinc value and/or sync the two data dictionaries to resume
normal operations.
Fix Bug#44030 Error: (1500) Couldn't read the MAX(ID) autoinc value from the
index (PRIMARY)
rb://118
The server was not cleaning the last IO error and error number when
resetting slave.
This patch addresses this issue by backporting into 5.1 part of the
patch in BUG 34654. A fix for this issue had already been pushed into
6.0 as part of the aforementioned bug, however the patch also included
some refactoring. The fix for 5.1 does not take into account the
refactoring part.
------------------------------------------------------------------------
r5150 | vasil | 2009-05-27 18:56:03 +0300 (Wed, 27 May 2009) | 4 lines
branches/5.1:
Whitespace fixup.
------------------------------------------------------------------------
r5191 | vasil | 2009-05-30 17:46:05 +0300 (Sat, 30 May 2009) | 19 lines
branches/5.1:
Merge a change from MySQL (this fixes the failing innodb_mysql test):
------------------------------------------------------------
revno: 1810.3894.10
committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
branch nick: mysql-5.0-bugteam
timestamp: Tue 2009-05-19 11:32:21 +0500
message:
Bug#39793 Foreign keys not constructed when column has a '#' in a comment or default value
Internal InnoDN FK parser does not recognize '\'' as quotation symbol.
Suggested fix is to add '\'' symbol check for quotation condition
(dict_strip_comments() function).
modified:
innobase/dict/dict0dict.c
mysql-test/r/innodb_mysql.result
mysql-test/t/innodb_mysql.test
------------------------------------------------------------------------
r5233 | marko | 2009-06-03 15:12:44 +0300 (Wed, 03 Jun 2009) | 11 lines
branches/5.1: Merge the test case from r5232 from branches/5.0:
------------------------------------------------------------------------
r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines
branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565
(Update Query Results in "1 Row Affected" But Should Be "Zero Rows").
Also, add a test case for Bug #40565.
rb://128 approved by Heikki Tuuri
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
r5232 | marko | 2009-06-03 14:31:04 +0300 (Wed, 03 Jun 2009) | 21 lines
branches/5.0: Merge r3590 from branches/5.1 in order to fix Bug #40565
(Update Query Results in "1 Row Affected" But Should Be "Zero Rows").
Also, add a test case for Bug #40565.
rb://128 approved by Heikki Tuuri
------------------------------------------------------------------------
The crash happens due to wrong max_length value which is set on
Item_func_round::fix_length_and_dec() stage. The value is set to
args[0]->max_length which is too big in case of LONGTEXT(LONGBLOB) fields.
The fix is to set max_length using float_length() function.
BEGIN/COMMIT/ROLLBACK was subject to replication db rules, and
caused the boundary of a transaction not recognized correctly
when these queries were ignored by the rules.
Fixed the problem by skipping replication db rules for these
statements.
