1. Fixes BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc value
from the index (PRIMARY)
2. Disables the innodb-autoinc test for innodb plugin temporarily.
The testcase for this bug has different result file for InnoDB plugin.
Should add the testcase to Innodb suite with a different result file.
Detailed revision comments:
r5243 | sunny | 2009-06-04 03:17:14 +0300 (Thu, 04 Jun 2009) | 14 lines
branches/5.1: When the InnoDB and MySQL data dictionaries go out of sync, before
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
r5252 | sunny | 2009-06-04 10:16:24 +0300 (Thu, 04 Jun 2009) | 2 lines
branches/5.1: The version of the result file checked in was broken in r5243.
r5259 | vasil | 2009-06-05 10:29:16 +0300 (Fri, 05 Jun 2009) | 7 lines
branches/5.1:
Remove the word "Error" from the printout because the mysqltest suite
interprets it as an error and thus the innodb-autoinc test fails.
Approved by: Sunny (via IM)
r5466 | vasil | 2009-07-02 10:46:45 +0300 (Thu, 02 Jul 2009) | 6 lines
branches/5.1:
Adjust the failing innodb-autoinc test to conform to the latest behavior
of the MySQL code. The idea and the comment in innodb-autoinc.test come
from Sunny.
Bug#24509 - 2048 file descriptor limit on windows needs increasing, also
WL#3049 - improved Windows I/O
The patch replaces the use of the POSIX I/O interfaces in mysys on Windows with
the Win32 API calls (CreateFile, WriteFile, etc). The Windows HANDLE for the open
file is stored in the my_file_info struct, along with a flag for append mode
because the Windows API does not support opening files in append mode in all cases)
The default max open files has been increased to 16384 and can be increased further
by setting --max-open-files=<value> during the server start.
Another major change in this patch that almost all Windows specific file IO code
has been moved to a new file my_winfile.c, greatly reducing the amount of code
in #ifdef blocks within mysys, thus improving readability.
Minor enhancements:
- my_(f)stat() is changed to use __stati64 structure with 64 file size
and timestamps. It will return correct file size now (C runtime implementation
used to report outdated information)
- my_lock on Windows is prepared to handle additional timeout parameter
- after review : changed __WIN__ to _WIN32 in the new and changed code.
bzr branch mysql-5.1-performance-version mysql-trunk # Summit
cd mysql-trunk
bzr merge mysql-5.1-innodb_plugin # which is 5.1 + Innodb plugin
bzr rm innobase # remove the builtin
Next step: build, test fixes.
This is a post-push fix addressing review requests and
problems with extra warnings.
Problem 1: The sub-statement where an unsafe warning was detected was
printed as part of the warning. This was ok for statements that
were unsafe due to, e.g., calls to UUID(), but did not make
sense for statements that were unsafe because there was more than
one autoincrement column (unsafeness in this case comes from the
combination of several sub-statements).
Fix 1: Instead of printing the sub-statement, print an explanation
of why the statement is unsafe.
Problem 2:
When a recursive construct (i.e., stored proceure, stored
function, trigger, view, prepared statement) contained several
sub-statements, and at least one of them was unsafe, there would be
one unsafeness warning per sub-statement - even for safe
sub-statements.
Fix 2:
Ensure that each type of warning is printed at most once, by
remembering throughout the execution of the statement which types
of warnings have been printed.
NOTE: This undoes changes by BUG#42829 in sql_class.cc:binlog_query().
I will revert the change in a post-push fix (the binlog filter should
be checked in sql_base.cc:decide_logging_format()).
General overview:
The logic for switching to row format when binlog_format=MIXED had
numerous flaws. The underlying problem was the lack of a consistent
architecture.
General purpose of this changeset:
This changeset introduces an architecture for switching to row format
when binlog_format=MIXED. It enforces the architecture where it has
to. It leaves some bugs to be fixed later. It adds extensive tests to
verify that unsafe statements work as expected and that appropriate
errors are produced by problems with the selection of binlog format.
It was not practical to split this into smaller pieces of work.
Problem 1:
To determine the logging mode, the code has to take several parameters
into account (namely: (1) the value of binlog_format; (2) the
capabilities of the engines; (3) the type of the current statement:
normal, unsafe, or row injection). These parameters may conflict in
several ways, namely:
- binlog_format=STATEMENT for a row injection
- binlog_format=STATEMENT for an unsafe statement
- binlog_format=STATEMENT for an engine only supporting row logging
- binlog_format=ROW for an engine only supporting statement logging
- statement is unsafe and engine does not support row logging
- row injection in a table that does not support statement logging
- statement modifies one table that does not support row logging and
one that does not support statement logging
Several of these conflicts were not detected, or were detected with
an inappropriate error message. The problem of BUG#39934 was that no
appropriate error message was written for the case when an engine
only supporting row logging executed a row injection with
binlog_format=ROW. However, all above cases must be handled.
Fix 1:
Introduce new error codes (sql/share/errmsg.txt). Ensure that all
conditions are detected and handled in decide_logging_format()
Problem 2:
The binlog format shall be determined once per statement, in
decide_logging_format(). It shall not be changed before or after that.
Before decide_logging_format() is called, all information necessary to
determine the logging format must be available. This principle ensures
that all unsafe statements are handled in a consistent way.
However, this principle is not followed:
thd->set_current_stmt_binlog_row_based_if_mixed() is called in several
places, including from code executing UPDATE..LIMIT,
INSERT..SELECT..LIMIT, DELETE..LIMIT, INSERT DELAYED, and
SET @@binlog_format. After Problem 1 was fixed, that caused
inconsistencies where these unsafe statements would not print the
appropriate warnings or errors for some of the conflicts.
Fix 2:
Remove calls to THD::set_current_stmt_binlog_row_based_if_mixed() from
code executed after decide_logging_format(). Compensate by calling the
set_current_stmt_unsafe() at parse time. This way, all unsafe statements
are detected by decide_logging_format().
Problem 3:
INSERT DELAYED is not unsafe: it is logged in statement format even if
binlog_format=MIXED, and no warning is printed even if
binlog_format=STATEMENT. This is BUG#45825.
Fix 3:
Made INSERT DELAYED set itself to unsafe at parse time. This allows
decide_logging_format() to detect that a warning should be printed or
the binlog_format changed.
Problem 4:
LIMIT clause were not marked as unsafe when executed inside stored
functions/triggers/views/prepared statements. This is
BUG#45785.
Fix 4:
Make statements containing the LIMIT clause marked as unsafe at
parse time, instead of at execution time. This allows propagating
unsafe-ness to the view.
1. BUG#21704 - Renaming column does not update FK definition
2. Changes in mysql-test/include/mtr_warnings.sql so that the testcase
for BUG#21704 doesn't fail because of the warnings generated.
Detailed revision comments:
r5488 | vasil | 2009-07-09 19:16:44 +0300 (Thu, 09 Jul 2009) | 13 lines
branches/5.1:
Fix Bug#21704 Renaming column does not update FK definition
by checking whether a column that participates in a FK definition is being
renamed and denying the ALTER in this case.
The patch was originally developed by Davi Arnaut <Davi.Arnaut@Sun.COM>:
http://lists.mysql.com/commits/77714
and was later adjusted to conform to InnoDB coding style by me (Vasil),
I also added some more comments and moved the bug specific mysql-test to
a separate file to make it more manageable and flexible.
BUG#45749 - Race condition in SET GLOBAL innodb_commit_concurrency=DEFAULT
Detailed revision comments:
r5419 | marko | 2009-06-25 16:11:57 +0300 (Thu, 25 Jun 2009) | 18 lines
branches/5.1: Merge r5418 from branches/zip:
------------------------------------------------------------------------
r5418 | marko | 2009-06-25 15:55:52 +0300 (Thu, 25 Jun 2009) | 5 lines
Changed paths:
M /branches/zip/ChangeLog
M /branches/zip/handler/ha_innodb.cc
M /branches/zip/mysql-test/innodb_bug42101-nonzero.result
M /branches/zip/mysql-test/innodb_bug42101-nonzero.test
M /branches/zip/mysql-test/innodb_bug42101.result
M /branches/zip/mysql-test/innodb_bug42101.test
branches/zip: Fix a race condition caused by
SET GLOBAL innodb_commit_concurrency=DEFAULT. (Bug #45749)
When innodb_commit_concurrency is initially set nonzero,
DEFAULT would change it back to 0, triggering Bug #42101.
rb://139 approved by Heikki Tuuri.
------------------------------------------------------------------------
BUG#42101 - Race condition in innodb_commit_concurrency
Detailed revision comments:
r4994 | marko | 2009-05-14 15:04:55 +0300 (Thu, 14 May 2009) | 18 lines
branches/5.1: Prevent a race condition in innobase_commit() by ensuring
that innodb_commit_concurrency>0 remains constant at run time. (Bug #42101)
srv_commit_concurrency: Make this a static variable in ha_innodb.cc.
innobase_commit_concurrency_validate(): Check that innodb_commit_concurrency
is not changed from or to 0 at run time. This is needed, because
innobase_commit() assumes that innodb_commit_concurrency>0 remains constant.
Without this limitation, the checks for innodb_commit_concurrency>0
in innobase_commit() should be removed and that function would have to
acquire and release commit_cond_m at least twice per invocation.
Normally, innodb_commit_concurrency=0, and introducing the mutex operations
would mean significant overhead.
innodb_bug42101.test, innodb_bug42101-nonzero.test: Test cases.
rb://123 approved by Heikki Tuuri
This patch fixes compilation warning, "conversion from 'time_t' to 'ulong',
possible loss of data".
The fix is to typecast time_t to ulong before assigning it to ulong.
Backported this from 6.0-bugteam tree.
1) BUG#43660 - SHOW INDEXES/ANALYZE does NOT update cardinality
for indexes of InnoDB table
Detailed revision comments:
r4699 | vasil | 2009-04-09 14:01:52 +0300 (Thu, 09 Apr 2009) | 15 lines
branches/5.1:
Fix Bug#43660 SHOW INDEXES/ANALYZE does NOT update cardinality for indexes
of InnoDB table
by replacing the PRNG that is used to pick random pages with a better
one.
This is based on r4670 but also adds a new configuration option and
enables the fix only if this option is changed. Please skip the present
revision when merging.
Approved by: Heikki (via email)
Bug #43203 Overflow from auto incrementing causes server segv
Detailed revision comments:
r4325 | sunny | 2009-03-02 02:28:52 +0200 (Mon, 02 Mar 2009) | 10 lines
branches/5.1: Bug#43203: Overflow from auto incrementing causes server segv
It was not a SIGSEGV but an assertion failure. The assertion was checking
the invariant that *first_value passed in by MySQL doesn't contain a value
that is greater than the max value for that type. The assertion has been
changed to a check and if the value is greater than the max we report a
generic AUTOINC failure.
rb://93
Approved by Heikki
Bug #42714 AUTO_INCREMENT errors in 5.1.31
Detailed revision comments:
r4287 | sunny | 2009-02-25 05:32:01 +0200 (Wed, 25 Feb 2009) | 10 lines
branches/5.1: Fix Bug#42714 AUTO_INCREMENT errors in 5.1.31. There are two
changes to the autoinc handling.
1. To fix the immediate problem from the bug report, we must ensure that the
value written to the table is always less than the max value stored in
dict_table_t.
2. The second related change is that according to MySQL documentation when
the offset is greater than the increment, we should ignore the offset.
Bug #42400 InnoDB autoinc code can't handle floating-point columns
Detailed revision comments:
r4065 | sunny | 2009-01-29 16:01:36 +0200 (Thu, 29 Jan 2009) | 8 lines
branches/5.1: In the last round of AUTOINC cleanup we assumed that AUTOINC
is only defined for integer columns. This caused an assertion failure when
we checked for the maximum value of a column type. We now calculate the
max value for floating-point autoinc columns too.
Fix Bug#42400 - InnoDB autoinc code can't handle floating-point columns
rb://84 and Mantis issue://162
r4111 | sunny | 2009-02-03 22:06:52 +0200 (Tue, 03 Feb 2009) | 2 lines
branches/5.1: Add the ULL suffix otherwise there is an overflow.
Improved data typing of server variables in InnoDB to avoid bugs on
Windows.
Workaround for bug in gcc assembler on 32-bit Mac OS X as well as
on Solaris.
- Remove bothersome warning messages. This change focuses on the warnings
that are covered by the ignore file: support-files/compiler_warnings.supp.
- Strings are guaranteed to be max uint in length
1) Buffer Pool size now defaults to 1GB and a minimum of 64MB
2) Log files are 3 by default and each 128MB in size
3) Removed innodb-file-io-threads config variable since no longer used
4) Set read io and write io threads to 8 by default for better default performance
5) Set log buffer size to 16 MB by default and minimum to 2MB
6) Set additional memory buffer pool to 8 MB and minimum to 2MB
7) Set max dirty percent to 75% and decreased to 99% to never allow a completely dirty buffer pool
8) Increased io capacity to 200 for a good default
There was a type casting problem in the storage/innobase/handler/ha_innodb.cc,
(int ha_innobase::write_row(...)). Innobase uses has an internal error variable
of type 'ulint' while mysql uses an 'int'.
To fix the problem the function manipulates an error variable of
type 'ulint' and only casts it into 'int' when needs to return the value.
Detailed description of changes:
r3601 | marko | 2008-12-22 16:05:19 +0200 (Mon, 22 Dec 2008) | 9 lines
branches/5.1: Make
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
a true replacement of SET GLOBAL INNODB_LOCKS_UNSAFE_FOR_BINLOG=1.
This fixes an error that was introduced in r370, causing
semi-consistent read not to not unlock rows in READ UNCOMMITTED mode.
(Bug #41671, Issue #146)
rb://67 approved by Heikki Tuuri
Detailed description of changes:
r3590 | marko | 2008-12-18 15:33:36 +0200 (Thu, 18 Dec 2008) | 11 lines
branches/5.1: When converting a record to MySQL format, copy the default
column values for columns that are SQL NULL. This addresses failures in
row-based replication (Bug #39648).
row_prebuilt_t: Add default_rec, for the default values of the columns in
MySQL format.
row_sel_store_mysql_rec(): Use prebuilt->default_rec instead of
padding columns.
rb://64 approved by Heikki Tuuri
Detailed description of changes:
r3257 | inaam | 2008-11-24 22:06:50 +0200 (Mon, 24 Nov 2008) | 13 lines
branches/5.1 bug#40760
The config param innodb_thread_concurrency is dynamically set and is
read when a thread enters/exits innodb. If the value is changed between
the enter and exit time the behaviour becomes erratic.
The fix is not to use srv_thread_concurrency when exiting, instead use
the flag trx->declared_to_be_inside_innodb.
rb://57
Approved by: Marko
Detailed description of changes:
r2981 | marko | 2008-11-07 14:54:10 +0200 (Fri, 07 Nov 2008) | 6 lines
branches/5.1: row_mysql_store_col_in_innobase_format(): Correct a misleading
comment. In the UTF-8 encoding, ASCII takes 1 byte per character, while
the "latin1" character set (normally ISO-8859-1, but in MySQL it actually
refers to the Windows Code Page 1252 a.k.a. CP1252, WinLatin1)
takes 1 to 3 bytes (1 to 2 bytes for the ISO-8859-1 subset).
r3114 | calvin | 2008-11-14 20:31:48 +0200 (Fri, 14 Nov 2008) | 8 lines
branches/5.1: fix bug#40386: Not flushing query cache after truncate
ha_statistics.records can not be 0 unless the table is empty, set to
1 instead. The original problem of bug 29507 is fixed in the server.
Additional test was done with the fix of bug 29507 in the server.
Approved by: Heikki (on IM)
Detailed description of changes:
r2902 | vasil | 2008-10-28 12:10:25 +0200 (Tue, 28 Oct 2008) | 10 lines
branches/5.1:
Fix Bug#38189 innodb_stats_on_metadata missing
Make the variable innodb_stats_on_metadata visible to the users and
also settable at runtime. Previously it was only "visible" as a command
line startup option to mysqld.
Approved by: Marko (https://svn.innodb.com/rb/r/36)
Bounds-checks and blocksize corrections were applied to user-input,
but constants in the server were trusted implicitly. If these values
did not actually meet the requirements, the user could not set change
a variable, then set it back to the (wonky) factory default or maximum
by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT).
Now checks also apply to the server's presets. Wonky values and maxima
get corrected at startup. Consequently all non-offsetted values the user
sees are valid, and users can set the variable to that exact value if
they so desire.
Bug #39830: Table autoinc value not updated on first insert.
Bug #35498: Cannot get table test/table1 auto-inccounter value in ::info
Bug #36411: Failed to read auto-increment value from storage engine" in 5.1.24 auto-inc
Detailed revision comments:
r2854 | sunny | 2008-10-23 08:30:32 +0300 (Thu, 23 Oct 2008) | 13 lines
branches/5.1: Backport changes from branches/zip r2725
Simplify the autoinc initialization code. This removes the
non-determinism related to reading the table's autoinc value for the first
time. This change has also reduced the sizeof dict_table_t by sizeof(ibool)
bytes because we don't need the dict_table_t::autoinc_inited field anymore.
rb://16
Bug #37788: InnoDB Plugin: AUTO_INCREMENT wrong for compressed tables
(Note, this bug is not only in the plugin, the overflow checks are relevant
for MySQL's InnoDB as well.)
Detailed revision comments:
r2852 | sunny | 2008-10-23 01:42:24 +0300 (Thu, 23 Oct 2008) | 9 lines
branches/5.1: Backport r2724 from branches/zip
Check column value against the col max value before updating the table's
global autoinc counter value. This is part of simplifying the AUTOINC
sub-system. We extract the type info from MySQL data structures at runtime.
Bug #40224: New AUTOINC changes mask reporting of deadlock/timeout errors
Detailed revision comments:
r2849 | sunny | 2008-10-22 12:01:18 +0300 (Wed, 22 Oct 2008) | 8 lines
branches/5.1: Return the actual error code encountered when allocating
a new autoinc value. The change in behavior (bug) was introduced in 5.1.22
when we introduced the new AUTOINC locking model.
rb://31
A follow-up to fix for bug #39438. This moves some errro messages from the
server error log to the client, to make it easier for users (especially in
shared hosting environment) to get info about why their statement is failing.
Detailed revision comments:
r2832 | vasil | 2008-10-21 10:08:30 +0300 (Tue, 21 Oct 2008) | 10 lines
branches/5.1:
In ha_innobase::info():
Replace sql_print_warning() which prints to mysqld error log with
push_warning_printf() which sends the error message to the client.
Suggested by: Marko, Sunny, Michael
Objected by: Inaam
Detailed revision comments:
r2826 | vasil | 2008-10-20 14:09:01 +0300 (Mon, 20 Oct 2008) | 5 lines
branches/5.1:
Non-functional change: use a single tab instead of 12 spaces between
variable type and variable name.
Detailed revision comments:
r2744 | marko | 2008-10-09 10:53:09 +0300 (Thu, 09 Oct 2008) | 5 lines
branches/5.1: ha_innobase::delete_all_rows(): In response to a user asking
<http://forums.innodb.com/read.php?4,215,215> why DELETE FROM t is not
mapped to TRUNCATE TABLE t as it is in MyISAM, note in a comment that
DELETE is transactional while TRUNCATE is not.
A follow-up fix for Bug 38839, which exposed a pre-existing bug in the
autoinc handling.
Detailed revision comments:
r2722 | sunny | 2008-10-04 02:48:04 +0300 (Sat, 04 Oct 2008) | 18 lines
branches/5.1: This bug has always existed but was masked by other errors. The
fix for bug# 38839 triggered this bug. When the offset and increment are > 1
we need to calculate the next value taking into consideration the two
variables. Previously we simply assumed they were 1 particularly offset was
never used. MySQL does its own calculation and that's probably why it seemed
to work in the past. We would return what we thought was the correct next
value and then MySQL would recalculate the actual value from that and return
it to the caller (e.g., handler::write_row()). Several new tests have been
added that try and catch some edge cases. The tests exposed a wrap around
error in MySQL next value calculation which was filed as bug 39828. The tests
will need to be updated once MySQL fix that bug.
One good side effect of this fix is that dict_table_t size has been
reduced by 8 bytes because we have moved the autoinc_increment field to
the row_prebuilt_t structure. See review-board for a detailed discussion.
rb://3
Send error message to the client when a rollback occurs when trying to get an
autoincrement value. This is related to the fixes for Bug#36411 and
Bug#35498.
Detailed revision comments:
r2721 | sunny | 2008-10-04 02:08:23 +0300 (Sat, 04 Oct 2008) | 6 lines
branches/5.1: We need to send the messages to the client because
handler::get_auto_increment() doesn't allow a way to return the
specific error for why it failed.
rb://18
A follow-up to the previous patch, fix for Bug #39438.
r2720 | vasil | 2008-10-03 19:52:39 +0300 (Fri, 03 Oct 2008) | 8 lines
branches/5.1:
Print a warning if an attempt is made to get the free space for a table
whose .ibd file is missing or the tablespace has been discarded. This is a
followup to r2719.
Suggested by: Inaam
