Commit graph

235 commits

Author SHA1 Message Date
Sergey Vojtovich
45e4c066e8 Merge fix for BUG51866 to mysql-5.1-bugteam. 2010-03-25 16:11:16 +04:00
Sergey Vojtovich
3f641968fc BUG#51866 - crash with repair by sort and fulltext keys
Repairing MyISAM table with fulltext indexes and low
myisam_sort_buffer_size may crash the server.

Estimation of number of index entries was done incorrectly,
causing further assertion failure or server crash.

Docs note: min value for myisam_sort_buffer_size has been
changed from 4 to 4096.
2010-03-25 16:08:21 +04:00
Sergey Vojtovich
4762eb64ec BUG#47444 - --myisam_repair_threads>1can result in all
index cardinalities=1

Parallel repair didn't poroperly update index cardinality
in certain cases.

When myisam_sort_buffer_size is not enough to store all
keys, index cardinality was updated before index was
actually written, when no index statistic is available.
2010-03-12 14:43:30 +04:00
Sergey Vojtovich
1e92b0fbe8 Merge fix for BUG51307 to 5.1-bugteam. 2010-03-10 16:32:12 +04:00
Sergey Vojtovich
1613b3e1dd BUG#51307 - widespread corruption with partitions and
insert...select

Queries following bulk insert into an empty MyISAM table
may break it. This was pure MyISAM problem.

When bulk insert into an empty table is complete, MyISAM
may want to enable indexes via repair by sort. If repair
by sort fails (e.g. insufficient buffer), MyISAM failover
to repair with key cache, requesting repair of data file.

Repair of data file performs data file substitution. This
means that current table instance will point to new data
file. Other cached table instances are still pointing to
an old, deleted data file.

This is fixed by not requesting repair of data file
during enable indexes.

Explicit REPAIR is not affected, since it flushes all
table instances.
2010-03-02 13:45:50 +04:00
Ramil Kalimullin
c1de4070ca Fix for bug#51304: checksum table gives different results
for same data when using bit fields

Problem: checksum for BIT fields may be computed incorrectly 
in some cases due to its storage peculiarity.

Fix: convert a BIT field to a string then calculate its checksum.
2010-02-28 21:29:19 +04:00
Sergey Vojtovich
d48d71b804 Merge fix for BUG48438 to mysql-5.1-bugteam. 2010-02-12 16:47:43 +04:00
Sergey Vojtovich
55a3e3a0b0 BUG#49628 - corrupt table after legal SQL, LONGTEXT column
Bulk REPLACE or bulk INSERT ... ON DUPLICATE KEY UPDATE may
break dynamic record MyISAM table.

The problem is limited to bulk REPLACE and INSERT ... ON
DUPLICATE KEY UPDATE, because only these operations may
be done via UPDATE internally and may request write cache.

When flushing write cache, MyISAM may write remaining
cached data at wrong position. Fixed by requesting write
cache to seek to a correct position.
2010-02-12 16:30:04 +04:00
Sergey Vojtovich
e766c177bb BUG#48438 - crash with error in unioned query against merge
table and view...

Invalid memory reads after a query referencing MyISAM table
multiple times with write lock. Invalid memory reads may
lead to server crash, valgrind warnings, incorrect values
in INFORMATION_SCHEMA.TABLES.{TABLE_ROWS, DATA_LENGTH,
INDEX_LENGTH, ...}.

This may happen when one of the table instances gets closed
after a query, e.g. out of slots in open tables cache. UNION,
MERGE and VIEW are irrelevant.

The problem was that MyISAM didn't restore state info
pointer to default value.
2010-02-12 15:28:38 +04:00
Ramil Kalimullin
7f7a1d5455 Auto-merge. 2009-12-17 10:52:43 +04:00
Ramil Kalimullin
092f25caeb Fix for bug#49465: valgrind warnings and incorrect live checksum...
Problem: inserting a record we don't set unused null bits in the
record buffer if no default field values used.
That may lead to wrong live checksum calculation.

Fix: set unused null bits in the record buffer in such cases.
2009-12-17 09:55:03 +04:00
Sergey Vojtovich
9fbc44eb09 A follow-up to fix for
BUG#47073 - valgrind errs, corruption,failed repair of partition,
            low myisam_sort_buffer_size

Fixed race conditions discovered with the provided test case and
stabilized test case.
2009-10-27 18:27:27 +04:00
Sergey Vojtovich
cd69e34ca7 Disabled part of test for BUG#47073 until additional fix is pushed. 2009-10-15 12:31:11 +05:00
Sergey Vojtovich
858713edd3 BUG#47073 - valgrind errs, corruption,failed repair of partition,
low myisam_sort_buffer_size

Repair by sort (default) or parallel repair of a MyISAM table
(doesn't matter partitioned or not) as well as bulk inserts
and enable indexes some times didn't failover to repair with
key cache.

The problem was that after unsuccessful attempt, data file was
closed. Whereas repair with key cache requires open data file.
Fixed by reopening data file.

Also fixed a valgrind warning, which may appear during repair
by sort or parallel repair with certain myisam_sort_buffer_size
number of rows and length of an index entry (very dependent).
2009-10-09 21:16:29 +05:00
Kristofer Pettersson
b2beff7415 Fix for BUG#35570 "CHECKSUM TABLE unreliable if LINESTRING field (same content/ differen
checksum)"

The problem was that checksum of GEOMETRY type used memory addresses
in the computation, making it un-repeatable thus useless.
(This patch is a backport from 6.0 branch)
2009-09-21 11:58:15 +02:00
Satya B
49e3fe95fe Addition to the fix for BUG#40827 - Killing insert-select to MyISAM can cause
table corruption


Moved the testcase from the file myisam.test to the new testfile 
mysiam_debug.test
2009-04-30 16:33:44 +05:30
Satya B
1cdd699022 Fix for BUG#40827 - Killing insert-select to MyISAM can cause table corruption
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.
2009-04-30 12:40:12 +05:30
Martin Hansson
7d24441119 Bug#43737: Select query return bad result
A bug in the initialization of key segment information made it point
to the wrong bit, since a bit index was used when its int value
was needed. This lead to misinterpretation of bit columns
read from MyISAM record format when a NULL bit pushed them over
a byte boundary.
Fixed by using the int value of the bit instead.
2009-04-29 14:00:34 +02:00
Satya B
f6c28cd948 BUG#40827 - Killing insert-select to MyISAM can cause table corruption
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.
2009-04-16 17:02:56 +05:30
He Zhenxing
6e86e05823 Merge 5.1 main -> 5.1-rpl 2008-09-06 08:51:17 +08:00
Ramil Kalimullin
47f3a9acfb Merge 2008-08-26 18:53:22 +05:00
Ramil Kalimullin
4d5670ebf9 Fix for bug #37310: 'on update CURRENT_TIMESTAMP' option crashes the table
Problem: data consistency check (maximum record length) for a correct
MyISAM table with CHECKSUM=1 and ROW_FORMAT=DYNAMIC option 
may fail due to wrong inner MyISAM parameter. In result we may 
have the table marked as 'corrupted'. 

Fix: properly set MyISAM maximum record length parameter.
2008-08-26 18:48:50 +05:00
Magnus Svensson
3d34d34c88 Merge 5.1->5.1-rpl
Fix paths and name of a few files to make it work with new mtr.pl
2008-05-30 11:12:07 +02:00
gshchepa/uchum@host.loc
ebc6e02dee Merge host.loc:/work/bugs/5.0-bugteam-30059
into  host.loc:/work/bk/5.1-bugteam
2008-05-13 17:01:02 +05:00
gshchepa/uchum@host.loc
1c45081b52 Partial rollback of fix for bug #30059: End-space truncation is inconsistent
or incorrect.

For better conformance with standard, truncation procedure of CHAR columns
has been changed to ignore truncation of trailing whitespace characters
(note has been removed).

Finally, for columns with non-binary charsets:

1. CHAR(N) columns silently ignore trailing whitespace truncation;
2. VARCHAR and TEXT columns issue Note about truncation.

BLOBs and other columns with BINARY charset are unaffected.
2008-05-06 21:43:46 +05:00
msvensson@pilot.mysql.com
95d9608d3e Fix paths in test and result files 2008-04-03 21:40:10 +02:00
istruewing@stella.local
eabe082d6f Manual merge 2008-03-14 12:02:11 +01:00
kaa@kaamos.(none)
9f194149b8 Merge kaamos.(none):/data/src/opt/mysql-5.0-opt
into  kaamos.(none):/data/src/opt/mysql-5.1-opt
2008-02-13 12:12:00 +03:00
gshchepa/uchum@host.loc
8715855aa0 Fixed bug#30059.
Server handles truncation for assignment of too-long values
into CHAR/VARCHAR/TEXT columns in a different ways when the
truncated characters are spaces:
1. CHAR(N) columns silently ignore end-space truncation;
2. TEXT columns post a truncation warning/error in the
   non-strict/strict mode.
3. VARCHAR columns always post a truncation note in
   any mode.

Space truncation processing has been synchronised over
CHAR/VARCHAR/TEXT columns: current behavior of VARCHAR
columns has been propagated as standard.

Binary-encoded string/BLOB columns are not affected.
2008-02-07 02:33:21 +04:00
istruewing@stella.local
8aebd394b8 Bug#29182 - MyISAMCHK reports wrong character set
myisamchk did always show Character set: latin1_swedish_ci (8),
regardless what DEFAULT CHARSET the table had.

When the server created a MyISAM table, it did not copy the
characterset number into the MyISAM create info structure.

Added assignment of charset number to MI_CREATE_INFO.
2008-01-24 18:56:42 +01:00
istruewing@stella.local
2658999591 Bug#32705 - myisam corruption: Key in wrong position
at page 1024 with ucs2_bin
Post merge fix
2008-01-16 15:38:40 +01:00
istruewing@stella.local
6eee6a3090 Merge stella.local:/home2/mydev/mysql-5.0-axmrg
into  stella.local:/home2/mydev/mysql-5.1-axmrg
2008-01-15 12:51:51 +01:00
istruewing@stella.local
7cc5885fdb Merge stella.local:/home2/mydev/mysql-5.1-bug33222
into  stella.local:/home2/mydev/mysql-5.1-axmrg
2008-01-15 10:24:18 +01:00
istruewing@stella.local
ad502388b6 Merge stella.local:/home2/mydev/mysql-5.0-bug32705
into  stella.local:/home2/mydev/mysql-5.0-axmrg
2008-01-15 09:43:47 +01:00
istruewing@stella.local
f126800b35 Bug#33222 - myisam-table drops rows when column is added
and a char-field > 128 exists

CHECK TABLE (non-QUICK) and any form of repair table did wrongly rate
records as corrupted under the following conditions:
1. The table has dynamic row format and
2. it has a CHAR like column > 127 bytes (but not VARCHAR)
   (for multi-byte character sets this could be less than 127
   characters) and
3. it has records with > 127 bytes significant length in that column
   (a byte beyond byte position 127 must be non-space).
Affected were the statements CHECK TABLE, REPAIR TABLE, OPTIMIZE TABLE,
ALTER TABLE. CHECK TABLE reported and marked the table as crashed if any
record was present that fulfilled condition 3. The other statements
deleted these records.

The problem was a signed/unsigned compare in MyISAM code. A
char to uchar change became necessary after the big byte to uchar
change.
2008-01-14 17:59:45 +01:00
istruewing@stella.local
cd1b00e8bb Bug#32705 - myisam corruption: Key in wrong position
at page 1024 with ucs2_bin

Inserting strings with a common prefix into a table with
characterset UCS2 corrupted the table.

An efficient search method was used, which compares end space
with ASCII blank. This doesn't work for character sets like UCS2,
which do not encode blank like ASCII does.

Use the less efficient search method _mi_seq_search()
for charsets with mbminlen > 1.
2007-12-18 12:29:50 +01:00
gluh@eagle.(none)
4f5868114a Merge mysql.com:/home/gluh/MySQL/Merge/5.1
into  mysql.com:/home/gluh/MySQL/Merge/5.1-opt
2007-12-13 15:56:04 +04:00
gluh@eagle.(none)
e039595029 Merge mysql.com:/home/gluh/MySQL/Merge/5.0
into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
2007-12-13 14:52:49 +04:00
kaa@polly.(none)
559b799d0b Merge polly.(none):/home/kaa/src/opt/bug28837/my51-bug29131
into  polly.(none):/home/kaa/src/opt/mysql-5.1-opt
2007-11-26 20:15:30 +03:00
kaa@polly.(none)
bc10c6db95 Merge polly.(none):/home/kaa/src/opt/bug28837/my50-bug29131
into  polly.(none):/home/kaa/src/opt/bug28837/my51-bug29131
2007-11-26 20:02:04 +03:00
kaa@polly.(none)
e854d43af9 Merge polly.(none):/home/kaa/src/opt/bug28837/my50-bug29131
into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt
2007-11-26 19:35:08 +03:00
kaa@polly.(none)
8fdd9087f8 Fix for bug #28837: MyISAM storage engine error (134) doing delete with
self-join

When doing DELETE with self-join on a MyISAM or MERGE table, it could
happen that a record being retrieved in join_read_next_same() has
already been deleted by previous iterations. That caused the engine's
index_next_same() method to fail with HA_ERR_RECORD_DELETED error and
the whole DELETE query to be aborted with an error.

Fixed by suppressing the HA_ERR_RECORD_DELETED error in
hy_myisam::index_next_same() and ha_myisammrg::index_next_same(). Since
HA_ERR_RECORD_DELETED can only be returned by MyISAM, there is no point
in filtering this error in the SQL layer.
2007-11-26 18:58:54 +03:00
istruewing@stella.local
0605274155 Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE
corrupts a MERGE table
Bug 26867 - LOCK TABLES + REPAIR + merge table result in
            memory/cpu hogging
Bug 26377 - Deadlock with MERGE and FLUSH TABLE
Bug 25038 - Waiting TRUNCATE
Bug 25700 - merge base tables get corrupted by
            optimize/analyze/repair table
Bug 30275 - Merge tables: flush tables or unlock tables
            causes server to crash
Bug 19627 - temporary merge table locking
Bug 27660 - Falcon: merge table possible
Bug 30273 - merge tables: Can't lock file (errno: 155)

The problems were:

Bug 26379 - Combination of FLUSH TABLE and REPAIR TABLE
                corrupts a MERGE table

  1. A thread trying to lock a MERGE table performs busy waiting while
     REPAIR TABLE or a similar table administration task is ongoing on
     one or more of its MyISAM tables.
  
  2. A thread trying to lock a MERGE table performs busy waiting until all
     threads that did REPAIR TABLE or similar table administration tasks
     on one or more of its MyISAM tables in LOCK TABLES segments do UNLOCK
     TABLES. The difference against problem #1 is that the busy waiting
     takes place *after* the administration task. It is terminated by
     UNLOCK TABLES only.
  
  3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate the
     lock. This does *not* require a MERGE table. The first FLUSH TABLES
     can be replaced by any statement that requires other threads to
     reopen the table. In 5.0 and 5.1 a single FLUSH TABLES can provoke
     the problem.

Bug 26867 - LOCK TABLES + REPAIR + merge table result in
            memory/cpu hogging

  Trying DML on a MERGE table, which has a child locked and
  repaired by another thread, made an infinite loop in the server.

Bug 26377 - Deadlock with MERGE and FLUSH TABLE

  Locking a MERGE table and its children in parent-child order
  and flushing the child deadlocked the server.

Bug 25038 - Waiting TRUNCATE

  Truncating a MERGE child, while the MERGE table was in use,
  let the truncate fail instead of waiting for the table to
  become free.

Bug 25700 - merge base tables get corrupted by
            optimize/analyze/repair table

  Repairing a child of an open MERGE table corrupted the child.
  It was necessary to FLUSH the child first.

Bug 30275 - Merge tables: flush tables or unlock tables
            causes server to crash

  Flushing and optimizing locked MERGE children crashed the server.

Bug 19627 - temporary merge table locking

  Use of a temporary MERGE table with non-temporary children
  could corrupt the children.

  Temporary tables are never locked. So we do now prohibit
  non-temporary chidlren of a temporary MERGE table.

Bug 27660 - Falcon: merge table possible

  It was possible to create a MERGE table with non-MyISAM children.

Bug 30273 - merge tables: Can't lock file (errno: 155)

  This was a Windows-only bug. Table administration statements
  sometimes failed with "Can't lock file (errno: 155)".

These bugs are fixed by a new implementation of MERGE table open.

When opening a MERGE table in open_tables() we do now add the
child tables to the list of tables to be opened by open_tables()
(the "query_list"). The children are not opened in the handler at
this stage.

After opening the parent, open_tables() opens each child from the
now extended query_list. When the last child is opened, we remove
the children from the query_list again and attach the children to
the parent. This behaves similar to the old open. However it does
not open the MyISAM tables directly, but grabs them from the already
open children.

When closing a MERGE table in close_thread_table() we detach the
children only. Closing of the children is done implicitly because
they are in thd->open_tables.

For more detail see the comment at the top of ha_myisammrg.cc.

Changed from open_ltable() to open_and_lock_tables() in all places
that can be relevant for MERGE tables. The latter can handle tables
added to the list on the fly. When open_ltable() was used in a loop
over a list of tables, the list must be temporarily terminated
after every table for open_and_lock_tables().
table_list->required_type is set to FRMTYPE_TABLE to avoid open of
special tables. Handling of derived tables is suppressed.
These details are handled by the new function
open_n_lock_single_table(), which has nearly the same signature as
open_ltable() and can replace it in most cases.

In reopen_tables() some of the tables open by a thread can be
closed and reopened. When a MERGE child is affected, the parent
must be closed and reopened too. Closing of the parent is forced
before the first child is closed. Reopen happens in the order of
thd->open_tables. MERGE parents do not attach their children
automatically at open. This is done after all tables are reopened.
So all children are open when attaching them.

Special lock handling like mysql_lock_abort() or mysql_lock_remove()
needs to be suppressed for MERGE children or forwarded to the parent.
This depends on the situation. In loops over all open tables one
suppresses child lock handling. When a single table is touched,
forwarding is done.

Behavioral changes:
===================

This patch changes the behavior of temporary MERGE tables.
Temporary MERGE must have temporary children.
The old behavior was wrong. A temporary table is not locked. Hence
even non-temporary children were not locked. See
Bug 19627 - temporary merge table locking.

You cannot change the union list of a non-temporary MERGE table
when LOCK TABLES is in effect. The following does *not* work:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
ALTER TABLE m1 ... UNION=(t1,t2) ...;
However, you can do this with a temporary MERGE table.

You cannot create a MERGE table with CREATE ... SELECT, neither
as a temporary MERGE table, nor as a non-temporary MERGE table.
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
Gives error message: table is not BASE TABLE.
2007-11-15 20:25:43 +01:00
istruewing@stella.local
500d5c788e Merge stella.local:/home2/mydev/mysql-5.0-bug4692
into  stella.local:/home2/mydev/mysql-5.1-bug4692
2007-11-14 12:51:36 +01:00
istruewing@stella.local
43a5312157 Bug#4692 - DISABLE/ENABLE KEYS waste a space
Post-pushbuild fix

Added a purecov comment and a test for coverage of parallel
enable keys.
2007-11-14 12:02:20 +01:00
istruewing@stella.local
e85cc0000a Bug#4692 - DISABLE/ENABLE KEYS waste a space
Post-merge fix. Moved test into 5.0 section.
2007-11-06 14:47:15 +01:00
istruewing@stella.local
30b409bd6f Bug#4692 - DISABLE/ENABLE KEYS waste a space
Disabling and enabling indexes on a non-empty table grows the
index file.

Disabling indexes just sets a flag per non-unique index and does not
free the index blocks of the affected indexes. Re-enabling indexes
creates new indexes with new blocks. The old blocks remain unused
in the index file.

Fixed by dropping and re-creating all indexes if non-empty disabled
indexes exist when enabling indexes. Dropping all indexes resets
the internal end-of-file marker to the end of the index file header.
It also clears the root block pointers of every index and clears the
deleted blocks chains. This way all blocks are declared as free.
2007-11-06 13:41:32 +01:00
istruewing@stella.local
7aa8144460 Merge stella.local:/home2/mydev/mysql-5.0-bug4692
into  stella.local:/home2/mydev/mysql-5.1-bug4692
2007-10-30 09:51:05 +01:00
istruewing@stella.local
8cc5fe116f Bug#4692 - DISABLE/ENABLE KEYS waste a space
Disabling and enabling indexes on a non-empty table grows the
index file.

Disabling indexes just sets a flag per non-unique index and does not
free the index blocks of the affected indexes. Re-enabling indexes
creates new indexes with new blocks. The old blocks remain unused
in the index file.

Fixed by dropping and re-creating all indexes if non-empty disabled
indexes exist when enabling indexes. Dropping all indexes resets
the internal end-of-file marker to the end of the index file header.
It also clears the root block pointers of every index and clears the
deleted blocks chains. This way all blocks are declared as free.
2007-10-26 15:29:06 +02:00
gkodinov/kgeorge@macbook.gmz
fe03f6bbe0 Bug #27531: 5.1 part of the fix
- Renamed "Using join cache" to "Using join buffer".
- "Using join buffer" is now printed on the last
  table that "reads" from the join buffer cache.
2007-05-29 15:58:18 +03:00