Commit graph

1242 commits

Author SHA1 Message Date
Joerg Bruehe
747fbf8f8b Merge the 5.5.22 release build into main 5.5,
conflict in "sql/filesort.cc" solved manually.
2012-03-20 22:27:49 +01:00
Joerg Bruehe
a70c8c4b20 Merge the 5.5.22 release build into main 5.5,
conflict in "sql/filesort.cc" solved manually.
2012-03-20 22:27:49 +01:00
Mattias Jonsson
5584e61f35 merge of bug#1364811 into mysql-5.5 2012-03-14 21:57:15 +01:00
Mattias Jonsson
aaf0e5d604 merge of bug#1364811 into mysql-5.5 2012-03-14 21:57:15 +01:00
Mattias Jonsson
58b2147833 bug#13694811
Updated code comments according to reviewers requests.
2012-03-14 20:36:42 +01:00
Mattias Jonsson
f8eb62625f bug#13694811
Updated code comments according to reviewers requests.
2012-03-14 20:36:42 +01:00
Mattias Jonsson
645bddecaf merge from mysql-5.1 2012-02-29 21:18:50 +01:00
Mattias Jonsson
cef28c88a3 merge from mysql-5.1 2012-02-29 21:18:50 +01:00
Mattias Jonsson
937ee6b7a0 merge into mysql-5.1 2012-02-29 20:51:38 +01:00
Mattias Jonsson
bd5f062f92 merge into mysql-5.1 2012-02-29 20:51:38 +01:00
Mattias Jonsson
8325fe02b3 Bug#13694811: THE OPTIMIZER WRONGLY USES THE FIRST INNODB
PARTITION STATISTICS

Problem was the fix for bug#11756867; It always used the first
partitions, and stopped after it checked 10 [sub]partitions.
(or until it found a partition which would contain a match).

This results in bad statistics for tables where the first 10 partitions
don't represent the majority of the data (like when the first 10
partitions only contained a few rows in total).

The solution was to take statisics from the partitions containing
the most rows instead:

Added an array of partition ids which is sorted by number of records
in descending order.

this array is used in records_in_range to cover as many records as
possible in as few calls as possible.

Also changed the limit of how many partitions to use for the statistics
from a static max of 10 partitions, into a dynamic model:
Maximum number of partitions is now log2(total number of partitions)
taken from the ordered array.
It will continue calling partitions records_in_range until it has 
checked:
(total rows in matching partitions) * (maximum number of partitions)
/ (number of used partitions)

Also reverted the changes for ha_partition::scan_time() and
ha_partition::estimate_rows_upper_bound() to before
the fix of  bug#11756867. Since they are not as slow as
records_in_range.
2012-02-22 23:13:36 +01:00
Mattias Jonsson
42282c10ce Bug#13694811: THE OPTIMIZER WRONGLY USES THE FIRST INNODB
PARTITION STATISTICS

Problem was the fix for bug#11756867; It always used the first
partitions, and stopped after it checked 10 [sub]partitions.
(or until it found a partition which would contain a match).

This results in bad statistics for tables where the first 10 partitions
don't represent the majority of the data (like when the first 10
partitions only contained a few rows in total).

The solution was to take statisics from the partitions containing
the most rows instead:

Added an array of partition ids which is sorted by number of records
in descending order.

this array is used in records_in_range to cover as many records as
possible in as few calls as possible.

Also changed the limit of how many partitions to use for the statistics
from a static max of 10 partitions, into a dynamic model:
Maximum number of partitions is now log2(total number of partitions)
taken from the ordered array.
It will continue calling partitions records_in_range until it has 
checked:
(total rows in matching partitions) * (maximum number of partitions)
/ (number of used partitions)

Also reverted the changes for ha_partition::scan_time() and
ha_partition::estimate_rows_upper_bound() to before
the fix of  bug#11756867. Since they are not as slow as
records_in_range.
2012-02-22 23:13:36 +01:00
Mattias Jonsson
74374933c8 Bug#11761296: 53775: QUERY ON PARTITIONED TABLE RETURNS CACHED
RESULT FROM PREVIOUS TRANSACTION

The current Query Cache API is not fully compatible with
the partitioning engine.

There is no good way to implement support for QC due to:
1) a static callback for ha_partition would need to have access
to all partition names and call the underlying callback for each
[sub]partition with the correct name.
2) pruning would be impossible, even if one used the ulonglong
engine_data due to if engine_data is changed, the table is
invalidated by the QC.

So the only viable solution to avoid incorrect data is to not allow
caching of queries using partitioned tables.

(There are some extra changes, due to removal of \r as line break)
2012-02-20 22:59:11 +01:00
Mattias Jonsson
7e21bee031 Bug#11761296: 53775: QUERY ON PARTITIONED TABLE RETURNS CACHED
RESULT FROM PREVIOUS TRANSACTION

The current Query Cache API is not fully compatible with
the partitioning engine.

There is no good way to implement support for QC due to:
1) a static callback for ha_partition would need to have access
to all partition names and call the underlying callback for each
[sub]partition with the correct name.
2) pruning would be impossible, even if one used the ulonglong
engine_data due to if engine_data is changed, the table is
invalidated by the QC.

So the only viable solution to avoid incorrect data is to not allow
caching of queries using partitioned tables.

(There are some extra changes, due to removal of \r as line break)
2012-02-20 22:59:11 +01:00
Sergei Golubchik
25609313ff 5.3.4 merge 2012-02-15 18:08:08 +01:00
Mattias Jonsson
7ebeb1433e Bug#13593865 - 64037: CRASH IN HA_PARTITION::CREATE_HANDLERS ON
ALTER TABLE AFTER DROP PARTITION
Bug#13608188 - 64038: CRASH IN HANDLER::HA_THD ON ALTER TABLE AFTER
                      REPAIR NON-EXISTING PARTITION

Backport of bug#13357766 from -trunk to -5.5.

The state of some partitions was not reset on failure, leading
to invalid states of partitions in consequent statements.

Fixed by reverting back to original state for all partitions
if not all partition names was resolved.

Also adding extra security by forcing tables to be reopened
in case of error in mysql_alter_table.

(There is also removal of \r at the end of some lines.)
2012-02-02 12:47:17 +01:00
Mattias Jonsson
98d3ef960d Bug#13593865 - 64037: CRASH IN HA_PARTITION::CREATE_HANDLERS ON
ALTER TABLE AFTER DROP PARTITION
Bug#13608188 - 64038: CRASH IN HANDLER::HA_THD ON ALTER TABLE AFTER
                      REPAIR NON-EXISTING PARTITION

Backport of bug#13357766 from -trunk to -5.5.

The state of some partitions was not reset on failure, leading
to invalid states of partitions in consequent statements.

Fixed by reverting back to original state for all partitions
if not all partition names was resolved.

Also adding extra security by forcing tables to be reopened
in case of error in mysql_alter_table.

(There is also removal of \r at the end of some lines.)
2012-02-02 12:47:17 +01:00
Sergei Golubchik
38e3ae155d mysql-5.5 merge 2012-01-16 20:16:35 +01:00
Sergei Golubchik
4f435bddfd 5.3 merge 2012-01-13 15:50:02 +01:00
Michael Widenius
5438d57315 Added Handler_read_rnd_deleted, number of deleted rows found with ha_read_rnd_first. 2012-01-13 14:35:49 +02:00
Sergei Golubchik
6cc9d0ffa0 move safemalloc out of dbug.
remeber a real backtrace for every allocation.
make safemalloc to tract C++ new/delete too.
collateral fixes to make the test suite pass.
2011-12-12 22:58:24 +01:00
Michael Widenius
6d4224a31c Merge with 5.2.
no_error handling for select (used by INSERT ... SELECT) still needs to be fixed, but I will do that in a separate commit
2011-12-11 11:34:44 +02:00
Michael Widenius
6920457142 Merge with MariaDB 5.1 2011-11-24 18:48:58 +02:00
Michael Widenius
7b368e3810 Merge with MySQL 5.1.60 2011-11-23 19:32:14 +02:00
Michael Widenius
a8d03ab235 Initail merge with MySQL 5.1 (XtraDB still needs to be merged)
Fixed up copyright messages.
2011-11-21 19:13:14 +02:00
Sergei Golubchik
6edd76785c merge 2011-11-03 23:39:53 +01:00
Sergei Golubchik
0e007344ea mysql-5.5.18 merge 2011-11-03 19:17:05 +01:00
Sergei Golubchik
90b43902b0 compilation warnings on Windows 2011-11-02 12:55:46 +01:00
Sergei Golubchik
76f0b94bb0 merge with 5.3
sql/sql_insert.cc:
  CREATE ... IF NOT EXISTS may do nothing, but
  it is still not a failure. don't forget to my_ok it.
  ******
  CREATE ... IF NOT EXISTS may do nothing, but
  it is still not a failure. don't forget to my_ok it.
sql/sql_table.cc:
  small cleanup
  ******
  small cleanup
2011-10-19 21:45:18 +02:00
Georgi Kodinov
e8313e13aa merge mysql-5.5->mysql-5.5-security 2011-10-12 15:07:15 +03:00
Georgi Kodinov
665ef20368 merge mysql-5.5->mysql-5.5-security 2011-10-12 15:07:15 +03:00
Mattias Jonsson
ab761db8d5 Bug#12696518: MEMORY LEAKS IN HA_PARTITION (VALGRIND TESTS ON TRUNK)
(also 5.5+ solution for bug#11766879/bug#60106)

The valgrind warning was due to an unused 'new handler_add_index(...)'
which was never freed.

The error handling did not work (fails as in bug#11766879) and
the implementation was not as transparant as it could, therefore I
made it a bit simpler and more transparant to the underlying handlers.

This way it follows the api better and the error handling works and
is also now tested.

Also added a debug test to verify the error handling.

Improved according to Jon Olavs review:
Added class ha_partition_add_index.
Also added base class Sql_alloc to handler_add_index.
Update 3.
2011-09-15 20:49:39 +02:00
Mattias Jonsson
7d1cccae44 Bug#12696518: MEMORY LEAKS IN HA_PARTITION (VALGRIND TESTS ON TRUNK)
(also 5.5+ solution for bug#11766879/bug#60106)

The valgrind warning was due to an unused 'new handler_add_index(...)'
which was never freed.

The error handling did not work (fails as in bug#11766879) and
the implementation was not as transparant as it could, therefore I
made it a bit simpler and more transparant to the underlying handlers.

This way it follows the api better and the error handling works and
is also now tested.

Also added a debug test to verify the error handling.

Improved according to Jon Olavs review:
Added class ha_partition_add_index.
Also added base class Sql_alloc to handler_add_index.
Update 3.
2011-09-15 20:49:39 +02:00
Mattias Jonsson
0fca226942 Bug#11766879/Bug#60106: DIFF BETWEEN # OF INDEXES IN MYSQL VS INNODB,
PARTITONING, ON INDEX CREATE

If the first partition succeeded in adding a index, but a successive partition failed,
then the first partition had still the new index.

The fix reverts the added indexes from previous partitions on failure.
2011-08-23 15:13:17 +02:00
Mattias Jonsson
e4fc9f6aa0 Bug#11766879/Bug#60106: DIFF BETWEEN # OF INDEXES IN MYSQL VS INNODB,
PARTITONING, ON INDEX CREATE

If the first partition succeeded in adding a index, but a successive partition failed,
then the first partition had still the new index.

The fix reverts the added indexes from previous partitions on failure.
2011-08-23 15:13:17 +02:00
Mats Kindahl
cf5e5f837a Merging into mysql-5.5.16-release. 2011-08-15 20:12:11 +02:00
Mats Kindahl
ee789c28b4 Merging into mysql-5.5.16-release. 2011-08-15 20:12:11 +02:00
Kent Boortz
027b5f1ed4 Updated/added copyright headers 2011-07-03 17:47:37 +02:00
Kent Boortz
b6e6097c95 Updated/added copyright headers 2011-07-03 17:47:37 +02:00
Sergei Golubchik
b4a0b2c2f8 post-merge fixes.
most tests pass.
5.3 merge is next
2011-07-02 22:12:12 +02:00
Sergei Golubchik
9809f05199 5.5-merge 2011-07-02 22:08:51 +02:00
Kent Boortz
68f00a5686 Updated/added copyright headers 2011-06-30 17:37:13 +02:00
Kent Boortz
1400d7a2cc Updated/added copyright headers 2011-06-30 17:37:13 +02:00
Michael Widenius
ba9a890f0c New status variables: Rows_tmp_read, Handler_tmp_update and Handler_tmp_write
Split status variable Rows_read to Rows_read and Rows_tmp_read so that one can see how much real data is read.
Same was done with with Handler_update and Handler_write.
Fixed bug in MEMORY tables where some variables was counted twice.
Added new internal handler call 'ha_close()' to have one place to gather statistics.
Fixed bug where thd->open_options was set to wrong value when doing admin_recreate_table()


mysql-test/r/status.result:
  Updated test results and added new tests
mysql-test/r/status_user.result:
  Udated test results
mysql-test/t/status.test:
  Added new test for temporary table status variables
sql/ha_partition.cc:
  Changed to call ha_close() instead of close()
sql/handler.cc:
  Added internal_tmp_table variable for easy checking of temporary tables.
  Added new internal handler call 'ha_close()' to have one place to gather statistics.
  Gather statistics for internal temporary tables.
sql/handler.h:
  Added handler variables internal_tmp_table, rows_tmp_read.
  Split function update_index_statistics() to two.
  Added ha_update_tmp_row() for faster tmp table handling with more statistics.
sql/item_sum.cc:
  ha_write_row() -> ha_write_tmp_row()
sql/multi_range_read.cc:
  close() -> ha_close()
sql/mysqld.cc:
  New status variables: Rows_tmp_read, Handler_tmp_update and Handler_tmp_write
sql/opt_range.cc:
  close() -> ha_close()
sql/sql_base.cc:
  close() -> ha_close()
sql/sql_class.cc:
  Added handling of rows_tmp_read
sql/sql_class.h:
  Added new satistics variables.
  rows_read++  ->  update_rows_read() to be able to correctly count reads to internal temp tables.
  Added handler::ha_update_tmp_row()
sql/sql_connect.cc:
  Added comment
sql/sql_expression_cache.cc:
  ha_write_row() -> ha_write_tmp_row()
sql/sql_select.cc:
  close() -> ha_close()
  ha_update_row() -> ha_update_tmp_row()
sql/sql_show.cc:
  ha_write_row() -> ha_write_tmp_row()
sql/sql_table.cc:
  Fixed bug where thd->open_options was set to wrong value when doing admin_recreate_table()
sql/sql_union.cc:
  ha_write_row() -> ha_write_tmp_row()
sql/sql_update.cc:
  ha_write_row() -> ha_write_tmp_row()
sql/table.cc:
  close() -> ha_close()
storage/heap/ha_heap.cc:
  Removed double counting of statistic variables.
  close -> ha_close() to get tmp table statistics.
storage/maria/ha_maria.cc:
  close -> ha_close() to get tmp table statistics.
2011-06-27 19:07:24 +03:00
Sergey Petrunya
7880039fc0 Merge 5.2 -> 5.3
(testcase for #798597 now crashes)
2011-06-24 21:43:31 +04:00
Mattias Jonsson
e827b51fa0 merge 2011-06-13 11:21:54 +02:00
Mattias Jonsson
44aa582bb3 merge 2011-06-13 11:09:56 +02:00
Michael Widenius
69ffc06610 Fixes BUG#60976 "Crash, valgrind warning and memory leak with partitioned archive tables"
Noted that there was no memory leak, just a lot of used partitioned tables.
Fixed old bug: 'show status' now shows memory usage when compiled with safemalloc.
Added option --flush to mysqlcheck.c to run a 'flush tables' between each check to keep down memory usage.
Changed '--safemalloc' options to mysqld so that one can use --safemalloc and --skip-safemalloc.
Now skip-safemalloc is default (ie, we only do checking of memory overrun during free()) to speed up tests.


client/client_priv.h:
  Added OPT_FLUSH_TABLES
client/mysqlcheck.c:
  Added option --flush to mysqlcheck.c to run a 'flush tables' between each check to keep down memory usage.
mysql-test/mysql-test-run.pl:
  Always run tests with --loose-skip-safemysqld for higher speed
sql/mysqld.cc:
  Changed '--safemalloc' options so that one can use --safemalloc and --skip-safemalloc.
  Now skip-safemalloc is default (ie, we only do checking of memory overrun during free()) to speed up tests
sql/sql_parse.cc:
  Fixed old bug: 'show status' now shows memory usage when compiled with safemalloc.
storage/archive/archive_reader.c:
  Changed all malloc() calls to use my_malloc()/my_free()
  Added checks of malloc() calls.
storage/archive/ha_archive.cc:
  Detect failure if init_archive_reader() and return errno. This fixed assert crash in my_seek().
  Changed all malloc() calls to use my_malloc()/my_free()
2011-06-11 14:28:15 +03:00
Mattias Jonsson
8f3bb95a43 merge 2011-06-13 11:09:56 +02:00
Jon Olav Hauglid
9b076952ec Bug#11853126 RE-ENABLE CONCURRENT READS WHILE CREATING
SECONDARY INDEX IN INNODB

The patches for Bug#11751388 and Bug#11784056 enabled concurrent
reads while creating secondary indexes in InnoDB. However, they
introduced a regression. This regression occured if ALTER TABLE
failed after the index had been added, for example during the
lock upgrade needed to update .FRM. If this happened, InnoDB
and the server got out of sync with regards to which indexes
actually existed. Therefore the patch for Bug#11815600 again
disabled concurrent reads.

This patch re-enables concurrent reads. The original regression
is fixed by splitting the ADD INDEX operation into two parts.
First the new index is created but not made active. This is
done while concurrent reads are allowed. The second part of
the operation makes the index active (or reverts the change).
This is done after lock upgrade, which prevents the original
regression.

In order to implement this change, the patch changes the storage
API for in-place index creation. handler::add_index() is split
into two functions, handler_add_index() and
handler::final_add_index(). The former for creating indexes without
making them visible and the latter for commiting (i.e. making
visible) new indexes or reverting the changes.

Large parts of this patch were written by Marko Mäkelä.

Test case added to innodb_mysql_lock.test.
2011-06-01 10:06:55 +02:00