- 05 Nov, 2006 3 commits
- 03 Nov, 2006 3 commits
-
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-cleanup
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-cleanup mysql-test/r/rename.result: Manual merge. mysql-test/t/rename.test: Manual merge.
-
unknown authored
mysql-test/r/rename.result: Update result. mysql-test/t/rename.test: Remove the race by replacing sleep with a reap.
-
- 02 Nov, 2006 2 commits
- 01 Nov, 2006 8 commits
-
-
unknown authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge mysql-test/r/ndb_update.result: Auto merged mysql-test/t/func_gconcat.test: Auto merged sql/ha_myisammrg.cc: Auto merged sql/ha_ndbcluster.cc: Auto merged sql/item_func.cc: Auto merged sql/item_func.h: Auto merged sql/item_sum.cc: Auto merged sql/log_event.cc: Auto merged sql/mysql_priv.h: Auto merged sql/mysqld.cc: Auto merged sql/set_var.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_delete.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_update.cc: Auto merged
-
unknown authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge sql/item_sum.cc: Auto merged sql/sql_base.cc: Auto merged sql/sql_delete.cc: Auto merged sql/sql_lex.h: Auto merged sql/sql_select.cc: Auto merged sql/sql_view.cc: Auto merged
-
unknown authored
into bodhi.local:/opt/local/work/mysql-4.1-runtime mysql-test/r/ps.result: Auto merged mysql-test/t/func_gconcat.test: Auto merged sql/item_func.cc: Auto merged sql/item_func.h: Auto merged sql/item_sum.cc: Auto merged sql/log_event.cc: Auto merged sql/mysql_priv.h: Auto merged sql/mysqld.cc: Auto merged sql/set_var.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_delete.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_update.cc: Auto merged
-
unknown authored
bug#21052 ndb/src/mgmsrv/Services.cpp: revert bug to wait for "proper" bug fix
-
unknown authored
into mysql.com:/home/cps/mysql/trees/5.0-runtime-bug9191 configure.in: Auto merged include/my_time.h: Auto merged mysql-test/r/func_time.result: Auto merged mysql-test/r/timezone2.result: Auto merged mysql-test/t/func_time.test: Auto merged mysql-test/t/timezone2.test: Auto merged sql/mysql_priv.h: Auto merged sql/time.cc: Auto merged BitKeeper/deleted/.del-acinclude.m4~f4ab416bac5003: Auto merged sql-common/my_time.c: manual merge sql/item_timefunc.cc: manual merge sql/tztime.cc: manual merge
-
unknown authored
(4.1 version, with post-review fixes) The fix for another Bug (6439) limited FROM_UNIXTIME() to TIMESTAMP_MAX_VALUE which is 2145916799 or 2037-12-01 23:59:59 GMT, however unix timestamp in general is not considered to be limited by this value. All dates up to power(2,31)-1 are valid. This patch extends allowed TIMESTAMP range so, that max TIMESTAMP value is power(2,31)-1. It also corrects FROM_UNIXTIME() and UNIX_TIMESTAMP() functions, so that max allowed UNIX_TIMESTAMP() is power(2,31)-1. FROM_UNIXTIME() is fixed accordingly to allow conversion of dates up to 2038-01-19 03:14:07 UTC. The patch also fixes CONVERT_TZ() function to allow extended range of dates. The main problem solved in the patch is possible overflows of variables, used in broken-time representation to time_t conversion (required for UNIX_TIMESTAMP). acinclude.m4: Add new macro to check time_t range configure.in: Call the macro to check time_t range include/my_time.h: Move time-related defines to proper place. Add a function to perform a rough check if a TIMESTAMP value fits into the boundaries. Note: it is defined as "static inline", as otherwise libmysql won't compile (due to the way how gcc handles "inline" directive). mysql-test/r/func_time.result: Update test result mysql-test/r/timezone.result: Update test result mysql-test/r/timezone2.result: Update test result mysql-test/t/func_time.test: Add test for Bug#9191 and update test to be consistent with new TIMESTAMP boundaries mysql-test/t/timezone.test: Update old tests to be consistent with new TIMESTAMP boundaries mysql-test/t/timezone2.test: Update tests for convert_tz to be consistent with new TIMESTAMP boundaries sql/item_timefunc.cc: Fix convert_tz to allow dates from the new (extended) TIMESTAMP range sql/mysql_priv.h: Move time handling defaults to my_time.h sql-common/my_time.c: Because of increased TIMESTAMP_MAX_VALUE overflows in my_system_gmt_sec() became possible. Here we make it safe against the overflows by stepping back from the boundary dates which are likely to trigger them. sql/time.cc: Update TIME_to_timestamp to allow conversion of extended date range sql/tztime.cc: Fix new (4.1) implementation of broken-down time representation to time_t conversion routine to avoid overflows during conversion of boundary dates mysql-test/r/timezone4.result: New BitKeeper file ``mysql-test/r/timezone4.result'' mysql-test/t/timezone4-master.opt: New BitKeeper file ``mysql-test/t/timezone4-master.opt'' mysql-test/t/timezone4.test: New BitKeeper file ``mysql-test/t/timezone4.test''
-
unknown authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-hash-2 sql/sql_lex.cc: Auto merged sql/sql_lex.h: Auto merged
-
unknown authored
Use lazy initialization for Query_tables_list::sroutines hash. This step should significantly decrease amount of memory consumed by stored routines as we no longer will allocate chunk of memory required for this HASH for each statement in routine. include/hash.h: Introduced auxillary hash_init_opt() macro which simplifies lazy initialization of HASH objects. sql/sp.cc: Use lazy initialization for Query_tables_list::sroutines hash. This step should significantly decrease amount of memory consumed by stored routines as we no longer will allocate chunk of memory required for this HASH for each statement in routine. sql/sql_lex.cc: Use lazy initialization for Query_tables_list::sroutines hash. This step should significantly decrease amount of memory consumed by stored routines as we no longer will allocate chunk of memory required for this HASH for each statement in routine. sql/sql_lex.h: Updated comment describing Query_tables_list::sroutines to reflect that now we are use lazy initialization for this hash. Added constant for initial size of this hash.
-
- 31 Oct, 2006 2 commits
- 30 Oct, 2006 7 commits
-
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21915 sql/mysql_priv.h: Auto merged
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug21915
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21915 sql/mysql_priv.h: SCCS merged sql/mysqld.cc: SCCS merged
-
unknown authored
If the user has specified --max-connections=N or --table-open-cache=M options to the server, a warning could be given that some values were recalculated, and table-open-cache could be assigned greater value. Note that both warning and increase of table-open-cache were totally harmless. This patch fixes recalculation code to ensure that table-open-cache will be never increased automatically and that a warning will be given only if some values had to be decreased due to operating system limits. No test case is provided because we neither can't predict nor control operating system limits for maximal number of open files. sql/mysql_priv.h: Add constants for table_cache minimum and default values. sql/mysqld.cc: Fix max_connections and table_cache_size re-computation.
-
unknown authored
sql/sql_parse.cc: ALTER TABLE should not be affected by DONT_ALLOW_SHOW_COMMANDS (a bug that's there since version 1.1)
-
unknown authored
sql/sql_table.cc: Remove unused code (it's also made obsolete by work in 5.1)
-
unknown authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
- 27 Oct, 2006 9 commits
-
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb mysql-test/r/ctype_utf8.result: Auto merged mysql-test/t/ctype_utf8.test: Auto merged sql/sql_base.cc: Auto merged sql/sql_delete.cc: Auto merged sql/sql_lex.h: Auto merged sql/sql_select.cc: Auto merged sql/table.cc: Auto merged
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb sql/sql_select.cc: Auto merged
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb ndb/src/ndbapi/NdbTransaction.cpp: Auto merged
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/50-work ndb/src/ndbapi/NdbTransaction.cpp: Auto merged
-
unknown authored
Still leakage, make sure all unlinked operations are put back so they will be release (on failing blob operations, when AO_IgnoreError) ndb/src/ndbapi/NdbConnection.cpp: Still leakage, make sure all unlinked operations are put back so they will be release
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug22584 mysql-test/r/view.result: Manual merge. mysql-test/t/view.test: Manual merge.
-
unknown authored
a updatable view. When there's a VIEW on a base table that have AUTO_INCREMENT column, and this VIEW doesn't provide an access such column, after INSERT to such VIEW LAST_INSERT_ID() did not return the value just generated. This behaviour is intended and correct, because if the VIEW doesn't list some columns then these columns are effectively hidden from the user, and so any side effects of inserting default values to them. However, there was a bug that such statement inserting into a view would reset LAST_INSERT_ID() instead of leaving it unchanged. This patch restores the original value of LAST_INSERT_ID() instead of resetting it to zero. mysql-test/r/view.result: Add result for bug#22584: last_insert_id not updated after inserting a record through a updatable view. mysql-test/t/view.test: Add test case for bug#22584: last_insert_id not updated after inserting a record through a updatable view. sql/sql_parse.cc: When we have inserted into a view, and AUTO_INCREMENT column is not accessed from this view, instead of setting LAST_INSERT_ID to zero set it to the value it had before this statement was executed.
-
- 25 Oct, 2006 6 commits
-
-
unknown authored
into orca.ndb.mysql.com:/export/home/space/pekka/ndb/version/my50-ndb
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819 mysql-test/r/innodb_mysql.result: Auto merged mysql-test/t/innodb_mysql.test: Auto merged sql/sql_delete.cc: Auto merged
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug18819
-
unknown authored
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18819 mysql-test/r/innodb_mysql.result: Manual merge. mysql-test/t/innodb_mysql.test: Manual merge. sql/sql_delete.cc: Manual merge.
-
unknown authored
If the error happens during DELETE IGNORE, nothing could be send to the client, thus leaving it frozen expecting the reply. The problem was that if some error occurred, it wouldn't be reported to the client because of IGNORE, but neither success would be reported. MySQL 4.1 would not freeze the client, but will report ERROR 1105 (HY000): Unknown error instead, which is also a bug. The solution is to report success if we are in DELETE IGNORE and some non-fatal error has happened. mysql-test/r/innodb_mysql.result: Add result for bug#18819: DELETE IGNORE hangs on foreign key parent delete. mysql-test/t/innodb_mysql.test: Add test case for bug#18819: DELETE IGNORE hangs on foreign key parent delete. sql/sql_delete.cc: Report success if we have got an error, but we are in DELETE IGNORE, and the error is not fatal (if it is, it would be reported to the client).
-