Bug #18828: If InnoDB runs out of undo slots, it returns misleading 'table is full'
This is a backport of code already in 5.1+. The error message change referred
to in the detailed revision comments is still pending.
Detailed revision comments:
r3937 | calvin | 2009-01-15 03:11:56 +0200 (Thu, 15 Jan 2009) | 17 lines
branches/5.0:
Backport the fix for Bug#18828. Return DB_TOO_MANY_CONCURRENT_TRXS
when we run out of UNDO slots in the rollback segment. The backport
is requested by MySQL under bug#41529 - Safe handling of InnoDB running
out of undo log slots.
This is a partial fix since the MySQL error code requested to properly
report the error condition back to the client has not yet materialized.
Currently we have #ifdef'd the error code translation in ha_innodb.cc.
This will have to be changed as and when MySQl add the new requested
code or an equivalent code that we can then use.
Given the above, currently we will get the old behavior, not the
"fixed" and intended behavior.
Approved by: Heikki (on IM)
- 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
branches/5.0 bug#39483 InnoDB hang on adaptive hash because of out
of order ::open() call by MySQL
Under some conditions MySQL calls ::open with search_latch leading
to a deadlock as we try to acquire dict_sys->mutex inside ::open
breaking the latching order. The fix is to release search_latch.
Reviewed by: Heikki
I think we don't need to issue an error statement in the convert_search_mode_to_innobase().
Returning the PAGE_CUR_UNSUPP value is enough as allows to handle this
case depending on the requirements.
per-file comments:
sql/ha_innodb.cc
Bug#31435 ha_innodb.cc:3983: ulint convert_search_mode_to_innobase(ha_rkey_function): Asse
no error issued in convert_search_mode_to_innobase.
ha_innobase::records_in_range() returns HA_POS_ERROR if search mode isn't supported.
innodb-5.0-ss2475.
Bug #34286 Assertion failure in thread 2816 in file .\row\row0sel.c line 3500
Since autoinc init performs a MySQL SELECT query to determine the auto-inc
value, set prebuilt->sql_stat_start = TRUE so that it is performed like any
normal SELECT, regardless of the context in which it was invoked.
Bug #35352 If InnoDB crashes with UNDO slots full error the error persists on restart
We've added a heuristic that checks the size of the UNDO slots cache lists
(insert and upate). If either of cached lists has more than 500 entries then we
add any UNDO slots that are freed, to the common free list instead of the cache
list, this is to avoid the case where all the free slots end up in only one of
the lists on startup after a crash.
Tested with test case for 26590 and passes all mysql-test(s).
Bug #36600 SHOW STATUS takes a lot of CPU in buf_get_latched_pages_number
Fixed by removing the Innodb_buffer_pool_pages_latched variable from SHOW
STATUS output in non-UNIV_DEBUG compilation.
Fixes:
Bug #32083: server crashes on show status when InnoDB is not initialized
innodb_export_status(): Check that InnoDB has been initialized
before invoking srv_export_innodb_status(). (Bug #32083)
This bug does not exist in MySQL/InnoDB 5.1.
Fixes the following bugs:
- Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock'
Fixed a race condition in the rw_lock where an os_event_reset()
can overwrite an earlier os_event_set() triggering an indefinite
wait.
NOTE: This fix for windows is different from that for other platforms.
NOTE2: This bug is introduced in the scalability fix to the
sync0arr which was applied to 5.0 only. Therefore, it need not be
applied to the 5.1 tree. If we decide to port the scalability fix
to 5.1 then this fix should be ported as well.
- Bug #32125: Database crash due to ha_innodb.cc:3896: ulint convert_search_mode_to_innobase
When unknown find_flag is encountered in convert_search_mode_to_innobase()
do not call assert(0); instead queue a MySQL error using my_error() and
return the error code PAGE_CUR_UNSUPP. Change the functions that call
convert_search_mode_to_innobase() to handle that error code by "canceling"
execution and returning appropriate error code further upstream.
Add --skip-innodb-adaptive-hash-index option, which is a way to
work around the bug (by disabling the adaptive hash feature entirely).
This may be useful even once the bug is fixed, for benchmarking purposes.
There are some workloads for which the adaptive hash index is not effective.
Apply innodb-5.0-ss1696 snapshot
Fixes:
- Bug#20090: InnoDB: Error: trying to declare trx to enter InnoDB
- Bug#23710: crash_commit_before fails if innodb_file_per_table=1
At InnoDB startup consider the case where log scan went beyond
checkpoint_lsn as a crash and initiate crash recovery code path.
- Bug#28781: InnoDB increments auto-increment value incorrectly with ON DUPLICATE KEY UPDATE
We need to do some special AUTOINC handling for the following case:
INSERT INTO t (c1,c2) VALUES(x,y) ON DUPLICATE KEY UPDATE ...
We need to use the AUTOINC counter that was actually used by
MySQL in the UPDATE statement, which can be different from the
value used in the INSERT statement.
- Bug#29097: fsp_get_available_space_in_free_extents() is capped at 4TB
Fix by typecasting the variables before multiplying them, so that the
result of the multiplication is of type "unsigned long long".
- Bug#29155: Innodb "Parallel recovery" is not prevented
Fix by enabling file locking on FreeBSD. It has been disabled because
InnoDB has refused to start on FreeBSD & LinuxThreads, but now it
starts just fine.
When innodb detects a deadlock it calls ha_rollback_trans() to rollback the
main transaction. But such action isn't allowed from inside of triggers and
functions. When it happen the 'Explicit or implicit commit' error is thrown
even if there is no commit/rollback statements in the trigger/function. This
leads to the user confusion.
Now the convert_error_code_to_mysql() function doesn't call the
ha_rollback_trans() function directly but rather calls the
mark_transaction_to_rollback function and returns an error.
The sp_rcontext::find_handler() now doesn't allow errors to be caught by the
trigger/function error handlers when the thd->is_fatal_sub_stmt_error flag
is set. Procedures are still allowed to catch such errors.
The sp_rcontext::find_handler function now accepts a THD handle as a parameter.
The transaction_rollback_request and the is_fatal_sub_stmt_error flags are
added to the THD class. The are initialized by the THD class constructor.
Now the ha_autocommit_or_rollback function rolls back main transaction
when not in a sub statement and the thd->transaction_rollback_request
is set.
The THD::restore_sub_statement_state function now resets the
thd->is_fatal_sub_stmt_error flag on exit from a sub-statement.
by long running transaction
On Windows opened files can't be deleted. There was a special
upgraded lock mode (TL_WRITE instead of TL_WRITE_ALLOW_READ)
in ALTER TABLE to make sure nobody has the table opened
when deleting the old table in ALTER TABLE. This special mode
was causing ALTER TABLE to hang waiting on a lock inside InnoDB.
This special lock is no longer necessary as the server is
closing the tables it needs to delete in ALTER TABLE.
Fixed by removing the special lock.
Note that this also reverses the fix for bug 17264 that deals with
another consequence of this special lock mode being used.
Apply innodb-5.0-* snapshots: ss1489 and ss1547.
Fixes:
Bug#9709: InnoDB inconsistensy causes "Operating System Error 32/33"
Bug#22819: SHOW INNODB STATUS crashes the server with an assertion failure under high load
Bug#25645: Assertion failure in file srv0srv.c
Bug#27294: insert into ... select ... causes crash with innodb_locks_unsafe_for_binlog=1
Bug#28138: indexing column prefixes produces corruption in InnoDB
(Part of fix for Bug#25621 Error in my_thread_global_end(): 1 threads didn't exit)
Give correct error message if InnoDB table is not found
(This allows us to drop a an innodb table that is not in the InnoDB registery)
INSERT into InnoDB table may cause "ERROR 1062 (23000): Duplicate entry..."
errors or lost records after multi-row INSERT of the form:
"INSERT INTO t (id...) VALUES (NULL...) ON DUPLICATE KEY UPDATE id=VALUES(id)",
where "id" is an AUTO_INCREMENT column.
It happens because InnoDB handler forgets to save next insert id after
updating of auto_increment column with new values. As result of that
last insert id stored inside InnoDB dictionary tables differs from it's
cached thd->next_insert_id value.
NULL MERGE: this ChangeSet will be null merged into mysql-5.1
Fixes:
- Bug #26662: mysqld assertion when creating temporary (InnoDB) table on a tmpfs filesystem
Fix by not open(2)ing with O_DIRECT but rather calling fcntl(2) to set
this flag immediately after open(2)ing. This way an error caused by
O_DIRECT not being supported can easily be ignored.
- Bug #23313: AUTO_INCREMENT=# not reported back for InnoDB tables
- Bug #21404: AUTO_INCREMENT value reset when Adding FKEY (or ALTER?)
Report the current value of the AUTO_INCREMENT counter to MySQL.
Apply the following InnoDB snapshots:
innodb-5.0-ss1319
innodb-5.0-ss1331
innodb-5.0-ss1333
innodb-5.0-ss1341
Fixes:
- Bug #21409: Incorrect result returned when in READ-COMMITTED with query_cache ON
At low transaction isolation levels we let each consistent read set
its own snapshot.
- Bug #23666: strange Innodb_row_lock_time_% values in show status; also millisecs wrong
On Windows ut_usectime returns secs and usecs relative to the UNIX
epoch (which is Jan, 1 1970).
- Bug #25494: LATEST DEADLOCK INFORMATION is not always cleared
lock_deadlock_recursive(): When the search depth or length is exceeded,
rewind lock_latest_err_file and display the two transactions at the
point of aborting the search.
- Bug #25927: Foreign key with ON DELETE SET NULL on NOT NULL can crash server
Prevent ALTER TABLE ... MODIFY ... NOT NULL on columns for which
there is a foreign key constraint ON ... SET NULL.
- Bug #26835: Repeatable corruption of utf8-enabled tables inside InnoDB
The bug could be reproduced as follows:
Define a table so that the first column of the clustered index is
a VARCHAR or a UTF-8 CHAR in a collation where sequences of bytes
of differing length are considered equivalent.
Insert and delete a record. Before the delete-marked record is
purged, insert another record whose first column is of different
length but equivalent to the first record. Under certain conditions,
the insertion can be incorrectly performed as update-in-place.
Likewise, an operation that could be done as update-in-place can
unnecessarily be performed as delete and insert, but that would not
cause corruption but merely degraded performance.
Applied innodb-5.0-ss1040 and innodb-5.0-ss1099 snapshots.
Bugs fixed:
- Bug #21468: InnoDB crash during recovery with corrupted data pages: XA bug?
- Bug #24299: Identifiers in foreign keys cannot contain U+0160, U+0360, ..., U+FF60
- Bug #24386: Performance degradation caused by instrumentation in mutex_struct
- Bug #24712: SHOW TABLE STATUS for file-per-table showing incorrect time fields
Fixed compiler warnings (detected by VC++):
- Removed not used variables
- Added casts
- Fixed wrong assignments to bool
- Fixed wrong calls with bool arguments
- Added missing argument to store(longlong), which caused wrong store method to be called.
(Mostly in DBUG_PRINT() and unused arguments)
Fixed bug in query cache when used with traceing (--with-debug)
Fixed memory leak in mysqldump
Removed warnings from mysqltest scripts (replaced -- with #)
This ChangeSet will be null-merged to mysql-5.1.
Bugs fixed:
- Bug #21638: InnoDB: possible segfault in page_copy_rec_list_end_no_locks
If prefix_len is specified, write it to the insert buffer instead of type->len
- bug #10746: InnoDB: Error: stored_select_lock_type is 0 inside ::start_stmt()!
INSERT ... SELECT uses LOCK_NONE in innodb_locks_unsafe_for_binlog mode, so do
not check for LOCK_X or LOCK_S in start_stmt()
Fixes:
- bug #19834: Using cursors when running in READ-COMMITTED can cause InnoDB to crash
- bug #21112: InnoDB slow with > 100,000 .ibd files
- bug #21113: Duplicate printout in SHOW INNODB STATUS
Fixes bug#17264, for alter table on win32 for successfull operation completion
it is used TL_WRITE(=10) lock instead of TL_WRITE_ALLOW_READ(=6), however here
in innodb handler TL_WRTIE is lifted to TL_WRITE_ALLOW_WRITE, which causes
race condition when several clients do alter table simultaneously.
Fixed BUG#15650: DELETE with LEFT JOIN crashes server
with innodb_locks_unsafe_for_binlog.
Fixed compilation problem with non-C99 compilers
in btr0sea.c
Fixed bugs:
#16814: SHOW INNODB STATUS format error in LATEST FOREIGN KEY ERROR section
dict_foreign_key_error_report(): Always print a newline after invoking
dict_print_info_on_foreign_key_in_create_format().
#16827: Better InnoDB error message if ibdata files omitted from my.cnf.
#17126: CHECK TABLE on InnoDB causes a short hang during check of adaptive hash.
CHECK TABLE blocking other queries, by releasing the btr_search_latch
periodically during the adaptive hash table validation.
#17405: Valgrind: conditional jump or move depends on uninitialised valuesw.
buf_block_init(): Reset magic_n, buf_fix_count, and io_fix to avoid testing
uninitialised variables.
#18077: InnoDB uses full explicit table locks in stored FUNCTION.
#18238: When locks exhaust the buffer pool, InnoDB does not roll back the trx.
Check in pessimistic insert and update if the buffer pool is exhausted by locks.
#18252: Disk space leaks in updates of InnoDB BLOB rows.
btr_cur_pessimistic_update(): Invoke rec_get_offset() after rec_set_field_extern_bits().
btr_store_big_rec_extern_fields(): Note that offsets will no longer be valid
after calling this function.
#18283: When InnoDB returns error 'lock table full', MySQL can write to binlog too much.
#18384: InnoDB memory leak on duplicate key errors if row has many columns.
row_ins_duplicate_error_in_clust(): Call mem_heap_free(heap) at func_exit if needed.
#18350: Use consistent read in CREATE ... SELECT .. if innodb_locks_unsafe_for_binlog is used.