Killing insert-select statement on MyISAM corrupts the table.
Killing the insert-select statement corrupts the MyISAM table only
when the destination table is empty and when it has indexes. When
we bulk insert huge data and if the destination table is empty we
disable the indexes for fast inserts, data is then inserted and
indexes are re-enabled after bulk_insert operation
Killing the query, aborts the repair table operation during enable
indexes phase leading to table corruption.
We now truncate the table when we detect that enable indexes is
killed for bulk insert query.As we have an empty table before the
operation, we can fix by truncating the table.
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)
problems
1) BUG#39320 - innodb crash in file btr/btr0pcur.c line 217 with
innodb_locks_unsafe_for_binlog
2) Fixes bug in multi-table semi consistent reads.
3) Fixes email address from dev@innodb.com to innodb_dev_ww@oracle.com
4) Fixes warning message generated by main.innodb test
Detailed revision comments:
r4399 | marko | 2009-03-12 09:38:05 +0200 (Thu, 12 Mar 2009) | 5 lines
branches/5.1: row_sel_get_clust_rec_for_mysql(): Store the cursor position
also for unlock_row(). (Bug #39320)
rb://96 approved by Heikki Tuuri.
r4400 | marko | 2009-03-12 10:06:44 +0200 (Thu, 12 Mar 2009) | 8 lines
branches/5.1: Fix a bug in multi-table semi-consistent reads.
Remember the acquired record locks per table handle (row_prebuilt_t)
rather than per transaction (trx_t), so that unlock_row should successfully
unlock all non-matching rows in multi-table operations.
This deficiency was found while investigating Bug #39320.
rb://94 approved by Heikki Tuuri.
r4481 | marko | 2009-03-19 15:01:48 +0200 (Thu, 19 Mar 2009) | 6 lines
branches/5.1: row_unlock_for_mysql(): Do not unlock records that were
modified by the current transaction. This bug was introduced or unmasked
in r4400.
rb://97 approved by Heikki Tuuri
r4573 | vasil | 2009-03-30 14:17:13 +0300 (Mon, 30 Mar 2009) | 4 lines
branches/5.1:
Fix email address from dev@innodb.com to innodb_dev_ww@oracle.com
r4574 | vasil | 2009-03-30 14:27:08 +0300 (Mon, 30 Mar 2009) | 38 lines
branches/5.1:
Restore the state of INNODB_THREAD_CONCURRENCY to silence this warning:
TEST RESULT TIME (ms)
------------------------------------------------------------
worker[1] Using MTR_BUILD_THREAD 250, with reserved ports 12500..12509
main.innodb [ pass ] 8803
MTR's internal check of the test case 'main.innodb' failed.
This means that the test case does not preserve the state that existed
before the test case was executed. Most likely the test case did not
do a proper clean-up.
This is the diff of the states of the servers before and after the
test case was executed:
mysqltest: Logging to '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.log'.
mysqltest: Results saved in '/tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result'.
mysqltest: Connecting to server localhost:12500 (socket /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
mysqltest: ... Connected.
mysqltest: Start processing test commands from './include/check-testcase.test' ...
mysqltest: ... Done processing test commands.
--- /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.result 2009-03-30 14:12:31.000000000 +0300
+++ /tmp/autotest.sh-20090330_033000-5.1.5Hg8CY/mysql-5.1/mysql-test/var/tmp/check-mysqld_1.reject 2009-03-30 14:12:41.000000000 +0300
@@ -99,7 +99,7 @@
INNODB_SUPPORT_XA ON
INNODB_SYNC_SPIN_LOOPS 20
INNODB_TABLE_LOCKS ON
-INNODB_THREAD_CONCURRENCY 8
+INNODB_THREAD_CONCURRENCY 16
INNODB_THREAD_SLEEP_DELAY 10000
INSERT_ID 0
INTERACTIVE_TIMEOUT 28800
mysqltest: Result content mismatch
not ok
r4576 | vasil | 2009-03-30 16:25:10 +0300 (Mon, 30 Mar 2009) | 4 lines
branches/5.1:
Revert a change to Makefile.am that I committed accidentally in c4574.
On IBM i 5.4, schemas with names that are longer
than 8 characters and contain digits or an underscore
cannot contain IBMDB2I tables, even though this should
theoritically be possible if all alpha characters
are uppercase.
THe current patch fixes the IBMDB2I engine to
allow digits and the underscore(_) to be used in
schema names longer than 8 characters on IBM i 5.4.
In some circumstances, when a table is created with
the IBMDB2I engine, the CREATE TABLE statement will
return successfully but the table will not exist.
The current patch addresses the above issue and causes
CREATE to fail and report and error to the user.
The utf8_swedish_ci and ucs2_swedish_ci
collations do not work with indexes on
IBMDB2I tables.
The current patch adds the mapping for
ucs2_swedish collation and removes the
ucs2_spanish2 mapping which is not
supported by any version of the operating
system.
Currently the memory map is being created
with a size that is greater than the size
of the underlying datafile. This can cause
varying behaviour,
e.g.
In windows the size of the datafile
is increased, while on linux it remains
the same.
This fix removes the increment margin to
the size that is used while creating the
memory map.
The conformance checker was not taking into
account, and, making concessions for acceptable
incompatibilites in tables created by
versions earlier than 4.1.
The current patch relaxes the conformance
checker to ignore differences in key_alg
and language for tables created by versions
earlier than 4.1.
Any statement reading corrupt archive data file
(CHECK/REPAIR/SELECT/UPDATE/DELETE) may cause assertion
failure in debug builds. This assertion has been removed
and an error is returned instead.
Also fixed that CHECK/REPAIR returns vague error message
when it mets corruption in archive data file. This is
fixed by returning proper error code.
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.
Bug #42279 Race condition in btr_search_drop_page_hash_when_freed()
Detailed revision comments:
r4032 | marko | 2009-01-23 15:43:51 +0200 (Fri, 23 Jan 2009) | 10 lines
branches/5.1: Merge r4031 from branches/5.0:
btr_search_drop_page_hash_when_freed(): Check if buf_page_get_gen()
returns NULL. The page may have been evicted from the buffer pool
between buf_page_peek_if_search_hashed() and buf_page_get_gen(),
because the buffer pool mutex will be released between these two calls.
(Bug #42279)
rb://82 approved by Heikki Tuuri
This problem comes while inserting a duplicate row in merge table
without key but the child table has a primary key.
While forming the error message handler tries to locate the key field
which is creating this problem but as there is no key on the merge
table there is a segmentation fault.
Bug #42152: Race condition in lock_is_table_exclusive()
Detailed revision comments:
r4005 | marko | 2009-01-20 16:22:36 +0200 (Tue, 20 Jan 2009) | 8 lines
branches/5.1: lock_is_table_exclusive(): Acquire kernel_mutex before
accessing table->locks and release kernel_mutex before returning from
the function. This fixes a portential race condition in the
"commit every 10,000 rows" in ALTER TABLE, CREATE INDEX, DROP INDEX,
and OPTIMIZE TABLE. (Bug #42152)
rb://80 approved by Heikki Tuuri
Bug #41571: MySQL segfaults after innodb recovery
Detailed revision comments:
r4004 | marko | 2009-01-20 16:19:00 +0200 (Tue, 20 Jan 2009) | 12 lines
branches/5.1: Merge r4003 from branches/5.0:
rec_set_nth_field(): When the field already is SQL null,
do nothing when it is being changed to SQL null. (Bug #41571)
Normally, MySQL does not pass "do-nothing" updates to the storage engine.
When it does and a column of an InnoDB table that is in ROW_FORMAT=COMPACT
is being updated from NULL to NULL, the InnoDB buffer pool will be corrupted
without this fix.
rb://81 approved by Heikki Tuuri
Bug #42075: dict_load_indexes failure in dict_load_table will corrupt the dictionary cache
Detailed revision comments:
r3930 | marko | 2009-01-14 15:51:30 +0200 (Wed, 14 Jan 2009) | 4 lines
branches/5.1: dict_load_table(): If dict_load_indexes() fails,
invoke dict_table_remove_from_cache() instead of dict_mem_table_free(),
so that the data dictionary will not point to freed data.
(Bug #42075, Issue #153, rb://76 approved by Heikki Tuuri)
Bug #38187: Error 153 when creating savepoints
Detailed revision comments:
r3911 | sunny | 2009-01-13 14:15:24 +0200 (Tue, 13 Jan 2009) | 13 lines
branches/5.1: Fix Bug#38187 Error 153 when creating savepoints
InnoDB previously treated savepoints as a stack e.g.,
SAVEPOINT a;
SAVEPOINT b;
SAVEPOINT c;
SAVEPOINT b; <- This would delete b and c.
This fix changes the behavior to:
SAVEPOINT a;
SAVEPOINT b;
SAVEPOINT c;
SAVEPOINT b; <- Does not delete savepoint c
The problem is that select queries executed concurrently with
a concurrent insert on a MyISAM table could be cached if the
select started after the query cache invalidation but before
the unlock of tables performed by the concurrent insert. This
race could happen because the concurrent insert was failing
to prevent cache of select queries happening at the same time.
The solution is to add a 'uncacheable' status flag to signal
that a concurrent insert is being performed on the table and
that queries executing at the same time shouldn't cache the
results.
Modify plugins.m4 configuration framework so that plugins which are
not built still get added to the source distribution during make dist.
This came up now because we can only build ibmdb2i on i5/OS, and we
can't bootstrap our source dist on that platform. The solution is to
specify DIST_SUBDIRS containing all plugins, separate from SUBDIRS
which contains the plugins which are actually built.
This ibmdb2i code is from the ibmdb2i-ga3-src.zip file, with a patch
to plug.in to disable the plugin if the PASE environment isn't available.
- 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
MyISAM did copy of key statistics incorrectly, which may cause
server crash or incorrect cardinality values. This may happen only on
platforms where size of long differs from size of pointer.
To determine number of bytes to be copied from array of ulong,
MyISAM mistakenly used sizoef(pointer) instead of sizeof(ulong).
