- 03 Dec, 2009 1 commit
-
-
Konstantin Osipov authored
-
- 02 Dec, 2009 1 commit
-
-
Alexander Nozdrin authored
-
- 01 Dec, 2009 2 commits
-
-
Andrei Elkin authored
Text conflict in mysql-test/collections/default.experimental Text conflict in mysql-test/r/show_check.result Text conflict in mysql-test/r/sp-code.result Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result Text conflict in mysql-test/suite/rpl/t/disabled.def Text conflict in mysql-test/t/show_check.test Text conflict in mysys/my_delete.c Text conflict in sql/item.h Text conflict in sql/item_cmpfunc.h Text conflict in sql/log.cc Text conflict in sql/mysqld.cc Text conflict in sql/repl_failsafe.cc Text conflict in sql/slave.cc Text conflict in sql/sql_parse.cc Text conflict in sql/sql_table.cc Text conflict in sql/sql_yacc.yy Text conflict in storage/myisam/ha_myisam.cc Corrected results for stm_auto_increment_bug33029.reject 2009-12-01 20:01:49.000000000 +0300 <andrei> @@ -42,9 +42,6 @@ <andrei> RETURN i; <andrei> END// <andrei> CALL p1(); <andrei> -Warnings: <andrei> -Note 1592 Statement may not be safe to log in statement format. <andrei> -Note 1592 Statement may not be safe to log in statement format. There should be indeed no Note present because there is in fact autoincrement top-level query in sp() that triggers inserting in yet another auto-inc table. (todo: alert DaoGang to improve the test).
-
Alexander Nozdrin authored
mysqld crashed in network_init()). The problem was that current_thd was not ready at that point in mysqld life, so ER() macro could not be used. The fix is to use ER_DEFAULT() macro, which is intented for such cases.
-
- 30 Nov, 2009 3 commits
-
-
Andrei Elkin authored
-
Andrei Elkin authored
merging from 5.1 to rep+2 starting at gca(5.1, next-mr) == build@mysql.com-20091104182209-iui387z35159aoyw
-
Horst.Hunger authored
-
- 28 Nov, 2009 1 commit
-
-
Serge Kozlov authored
-
- 27 Nov, 2009 4 commits
-
-
Serge Kozlov authored
-
Horst.Hunger authored
-
Horst.Hunger authored
-
Horst.Hunger authored
-
- 26 Nov, 2009 5 commits
-
-
Serge Kozlov authored
-
Magne Mahre authored
When the data directory contained a symbolic link to another file system, and the DATA or INDEX DIRECTORY clause of a CREATE TABLE statement referred to a subdirectory of the data directory, this was accepted. The problem was the use of a table file path name, which included the table name without an extension, for the comparison against the data directory path name. This was almost always a non-existent file. The internal algorithm failed to resolve symbolic links for non-existent files. So we compared unrelated path names. Fixed by truncating the table name from the path before resolving symlinks. If this is also a non-existent path, the creation of the table will fail anyway. Backport to 5.6.0. 6.0-codebase revid: 2599.60.1 sql/sql_table.cc: Changed test for data directory to exclude the table name from the comparison.
-
Magne Mahre authored
-
Horst.Hunger authored
-
Horst.Hunger authored
-
- 25 Nov, 2009 9 commits
-
-
Magne Mahre authored
.frm file Added FLUSH TABLES before myisampack --join operation to fix the test warnings or errors Removed unused variable in create_dest_frm() method
-
Magne Mahre authored
table .frm file Problem: ======== Myisampack --join did not create the destination table .frm file. The user had to copy one of the source table .frm file as destination .frm file for mysql server to recognize. This is just 'user-friendliness' issue. How it was solved ================= After successful join and compression we copy the frm file from the first source table. Functionality added =================== myisampack --join=/path/t3 /path/t1 /path/t2 creates /path/t3.frm (which is bascially copied from first table's frm /path/t1) Tests ===== Modified myisampack.test to test two scenario's 1. Positive myisampack --join test In this case after the join operation is done,we test if the destination table is accessible from the server 2. Positive myisampack --join test with an existing .frm file. We test the above case with an existing .frm file for the destination table. It should return success even in this case. 3. Positive myisampack --join test with no .frm file for source tables We test the join operation with no .frm files for source tables. It should complete the join operation without any warnings and error messages 4. Negative myisampack --join test We test myisampack --join with existing .MYI,.MDI,.frm files for the destination table. It should fail with exit status 2 in this case.
-
Magne Mahre authored
branch due to BUG#46853 Commented out the testcase for Bug#45816 in mysql-pe branch due to valgrind warnings. Please see Bug#46853
-
Magne Mahre authored
Select queries on archive tables when joined on their primary keys returns no results(empty set) Archive storage doesn't inform the handler about the fetched record status when it is found. Fixed the archive storage engine to update the record status when it fetches successfully
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alik authored
-
Alexander Nozdrin authored
The following 6.0 revisions were analyzed: - sp1r-brian@zim.(none)-20071228102738-21894 - sp1r-brian@zim.(none)-20071228121841-56447 - sp1r-brian@zim.(none)-20071228205403-56423 - sp1r-brian@zim.(none)-20071228221139-55341 - sp1r-brian@zim.(none)-20071228233443-55352 - sp1r-brian@zim.(none)-20071229094527-61763 - sp1r-brian@zim.(none)-20071230203739-61746 - sp1r-brian@zim.(none)-20080102213805-61741 - sp1r-brian@zim.(none)-20080103201041-61746 - sp1r-brian@zim.(none)-20080104234927-59875 - sp1r-brian@zim.(none)-20080105005827-59874 - sp1r-brian@zim.(none)-20080105012020-59865 - sp1r-brian@zim.(none)-20080106003858-59857 - sp1r-brian@zim.(none)-20080123195552-31680 - sp1r-brian@zim.(none)-20080124201848-29999 - sp1r-brian@zim.(none)-20080129075144-36991 - sp1r-cbell/Chuck@mysql_cab_desk.-20080215041806-21954 - sp1r-vvaintroub@wva.-20080212124547-06272 - sp1r-dfischer/mysqldev@mysql.com/production.mysql.com-20071223184258-15140 - sp1r-brian@zim.(none)-20080206122216-35774 - sp1r-baker@bk-internal.mysql.com-20080209005622-35947 - sp1r-baker@bk-internal.mysql.com-20080224215608-24613 - sp1r-baker@bk-internal.mysql.com-20080307170710-63543 - sp1r-baker@bk-internal.mysql.com-20080312233205-13069 - sp1r-Reggie@core.-20080402175211-28643 - kpettersson@mysql.com-20080901101150-4ne74r8v0492vv42 - alik@sun.com-20090805173811-9fzt0ymcp9tsvn7k - alik@sun.com-20090805173937-fcv1fdveodq5x9gb - alik@sun.com-20090805175009-g1od16i3t1xkw2qr - kostja@sun.com-20090805200643-j9i4fy7ii8ijho5c - alik@sun.com-20090807195303-j4fb5m4l1dgdahwo - alik@sun.com-20090808114848-3rkzr9kifrijzaqy - alik@sun.com-20090810041739-ugmx34h34uid8mox - alik@sun.com-20090810105306-rf43rfyzzblsy5e7 - alik@sun.com-20090810123113-ccdjwai68b5woqdm - alik@sun.com-20090811080423-gb7pibec1znaydzy - alik@sun.com-20090811082130-5uckar1vx3kdsw7g - alik@sun.com-20090812202051-uqkfwwxxcjvo5ean The following bugfixes are also backported within this patch: - Bug#34292: netdb.h missing in hostname.cc - Bug#39153: Failing to lookup a host name can lead to crash in current IPv6 implementation - Bug#38247: Server does not resolve connecting ip's - Bug#43006: main.skip_name_resolve fails on Windows in PB2 - Bug#45606: ACL requires IPv4-mapped addresses to be used - Bug#45584: Host name cache does not work as a cache
-
Alexander Nozdrin authored
-
- 24 Nov, 2009 7 commits
-
-
Marc Alff authored
-
Alexander Nozdrin authored
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 3559 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: mysql-pe timestamp: Fri 2009-08-28 15:23:16 -0300 message: Break down a large and obnoxious "if" statement. Multiple "if" statements makes it easy to understand and follow the code (specially in a debugger). sql/sql_base.cc: Break down a large and obnoxious "if" statement. Multiple "if" statements makes it easy to understand and follow the code (specially in a debugger).
-
Luis Soares authored
NOTE: backporting BUG#42150 into next-mr Includes latest Andrei's patch (see [2 Feb 18:40] Bugs System) and merge.test post-push fix (see [3 Feb 18:04] Bugs System) The reason of the bug appeared to be overreacting on absense of a binlog file although the file name had been presented in in the master binlog index file. By convention, there should have been only a warning printed and the rest of `reset master' logics completed. This did not happen on windows due to incorrect value of my_errno returned from nt_share_delete(). Fixed with correcting my_errno assignment in nt_share_delete() to be ENOENT in he event of no binlog file. Some minor refactoring has been made.
-
Konstantin Osipov authored
No commit message
-
Konstantin Osipov authored
---------------------------------------------------------------------- ChangeSet@1.2571, 2008-04-08 12:30:06+02:00, vvaintroub@wva. +122 -0 Bug#32082 : definition of VOID in my_global.h conflicts with Windows SDK headers VOID macro is now removed. Its usage is replaced with void cast. In some cases, where cast does not make much sense (pthread_*, printf, hash_delete, my_seek), cast is ommited. client/mysqladmin.cc: Bug#32082 : remove VOID macro client/mysqldump.c: Bug#32082 : remove VOID macro client/mysqlimport.c: Bug#32082 : remove VOID macro client/mysqlslap.c: Bug#32082 : remove VOID macro client/mysqltest.cc: Bug#32082 : remove VOID macro client/sql_string.cc: Bug#32082 : remove VOID macro extra/comp_err.c: Bug#32082 : remove VOID macro extra/replace.c: Bug#32082 : remove VOID macro include/my_alarm.h: Bug#32082 : remove VOID macro include/my_global.h: Bug#32082 : remove VOID macro libmysql/libmysql.c: Bug#32082 : remove VOID macro mysys/errors.c: Bug#32082 : remove VOID macro mysys/hash.c: Bug#32082 : remove VOID macro mysys/mf_iocache2.c: Bug#32082 : remove VOID macro mysys/mf_loadpath.c: Bug#32082 : remove VOID macro mysys/mf_path.c: Bug#32082 : remove VOID macro mysys/my_append.c: Bug#32082 : remove VOID macro mysys/my_clock.c: Bug#32082 : remove VOID macro mysys/my_copy.c: Bug#32082 : remove VOID macro mysys/my_fstream.c: Bug#32082 : remove VOID macro mysys/my_getwd.c: Bug#32082 : remove VOID macro mysys/my_lib.c: Bug#32082 : remove VOID macro mysys/my_lockmem.c: Bug#32082 : remove VOID macro mysys/my_pthread.c: Bug#32082 : remove VOID macro mysys/my_redel.c: Bug#32082 : remove VOID macro mysys/stacktrace.c: Bug#32082 : remove VOID macro mysys/thr_alarm.c: Bug#32082 : remove VOID macro mysys/thr_lock.c: Bug#32082 : remove VOID macro sql/derror.cc: Bug#32082 : remove VOID macro sql/des_key_file.cc: Bug#32082 : remove VOID macro sql/discover.cc: Bug#32082 : remove VOID macro sql/field.cc: Bug#32082 : remove VOID macro sql/filesort.cc: Bug#32082 : remove VOID macro sql/ha_ndbcluster.cc: Bug#32082 : remove VOID macro sql/ha_partition.cc: Bug#32082 : remove VOID macro sql/handler.cc: Bug#32082 : remove VOID macro sql/hostname.cc: Bug#32082 : remove VOID macro sql/init.cc: Bug#32082 : remove VOID macro sql/item.cc: Bug#32082 : remove VOID macro sql/item_cmpfunc.cc: Bug#32082 : remove VOID macro sql/item_strfunc.cc: Bug#32082 : remove VOID macro sql/lock.cc: Bug#32082 : remove VOID macro sql/log.cc: Bug#32082 : remove VOID macro sql/log_event.cc: Bug#32082 : remove VOID macro sql/mysqld.cc: Bug#32082 : remove VOID macro sql/opt_range.h: Bug#32082 : remove VOID macro sql/protocol.cc: Bug#32082 : remove VOID macro sql/records.cc: Bug#32082 : remove VOID macro sql/sp_head.cc: Bug#32082 : remove VOID macro sql/sp_pcontext.cc: Bug#32082 : remove VOID macro sql/sql_acl.cc: Bug#32082 : remove VOID macro sql/sql_base.cc: Bug#32082 : remove VOID macro sql/sql_cache.cc: Bug#32082 : remove VOID macro sql/sql_connect.cc: Bug#32082 : remove VOID macro sql/sql_db.cc: Bug#32082 : remove VOID macro sql/sql_delete.cc: Bug#32082 : remove VOID macro sql/sql_handler.cc: Bug#32082 : remove VOID macro sql/sql_insert.cc: Bug#32082 : remove VOID macro sql/sql_map.cc: Bug#32082 : remove VOID macro sql/sql_parse.cc: Bug#32082 : remove VOID macro sql/sql_select.cc: Bug#32082 : remove VOID macro sql/sql_servers.cc: Bug#32082 : remove VOID macro sql/sql_show.cc: Bug#32082 : remove VOID macro sql/sql_string.cc: Bug#32082 : remove VOID macro sql/sql_table.cc: Bug#32082 : remove VOID macro sql/sql_test.cc: Bug#32082 : remove VOID macro sql/sql_trigger.cc: Bug#32082 : remove VOID macro sql/sql_update.cc: Bug#32082 : remove VOID macro sql/sql_view.cc: Bug#32082 : remove VOID macro sql/table.cc: Bug#32082 : remove VOID macro sql/tztime.cc: Bug#32082 : remove VOID macro sql/udf_example.c: Bug#32082 : remove VOID macro sql/uniques.cc: Bug#32082 : remove VOID macro sql/unireg.cc: Bug#32082 : remove VOID macro storage/archive/ha_archive.cc: Bug#32082 : remove VOID macro storage/blackhole/ha_blackhole.cc: Bug#32082 : remove VOID macro storage/csv/ha_tina.cc: Bug#32082 : remove VOID macro storage/csv/transparent_file.cc: Bug#32082 : remove VOID macro storage/example/ha_example.cc: Bug#32082 : remove VOID macro storage/federated/ha_federated.cc: Bug#32082 : remove VOID macro storage/heap/hp_clear.c: Bug#32082 : remove VOID macro storage/heap/hp_create.c: Bug#32082 : remove VOID macro storage/heap/hp_test1.c: Bug#32082 : remove VOID macro storage/heap/hp_test2.c: Bug#32082 : remove VOID macro storage/innobase/handler/ha_innodb.cc: Bug#32082 : remove VOID macro storage/myisam/ft_eval.c: Bug#32082 : remove VOID macro storage/myisam/ha_myisam.cc: Bug#32082 : remove VOID macro storage/myisam/mi_changed.c: Bug#32082 : remove VOID macro storage/myisam/mi_check.c: Bug#32082 : remove VOID macro storage/myisam/mi_close.c: Bug#32082 : remove VOID macro storage/myisam/mi_create.c: Bug#32082 : remove VOID macro storage/myisam/mi_dbug.c: Bug#32082 : remove VOID macro storage/myisam/mi_delete.c: Bug#32082 : remove VOID macro storage/myisam/mi_delete_all.c: Bug#32082 : remove VOID macro storage/myisam/mi_dynrec.c: Bug#32082 : remove VOID macro storage/myisam/mi_info.c: Bug#32082 : remove VOID macro storage/myisam/mi_locking.c: Bug#32082 : remove VOID macro storage/myisam/mi_log.c: Bug#32082 : remove VOID macro storage/myisam/mi_open.c: Bug#32082 : remove VOID macro storage/myisam/mi_packrec.c: Bug#32082 : remove VOID macro storage/myisam/mi_panic.c: Bug#32082 : remove VOID macro storage/myisam/mi_rsame.c: Bug#32082 : remove VOID macro storage/myisam/mi_statrec.c: Bug#32082 : remove VOID macro storage/myisam/mi_test1.c: Bug#32082 : remove VOID macro storage/myisam/mi_test2.c: Bug#32082 : remove VOID macro storage/myisam/mi_test3.c: Bug#32082 : remove VOID macro storage/myisam/mi_update.c: Bug#32082 : remove VOID macro storage/myisam/mi_write.c: Bug#32082 : remove VOID macro storage/myisam/myisamchk.c: Bug#32082 : remove VOID macro storage/myisam/myisamlog.c: Bug#32082 : remove VOID macro storage/myisam/myisampack.c: Bug#32082 : remove VOID macro storage/myisam/sort.c: Bug#32082 : remove VOID macro storage/myisammrg/myrg_close.c: Bug#32082 : remove VOID macro storage/myisammrg/myrg_create.c: Bug#32082 : remove VOID macro storage/myisammrg/myrg_open.c: Bug#32082 : remove VOID macro strings/str_test.c: Bug#32082 : remove VOID macro tests/thread_test.c: Bug#32082 : remove VOID macro
-
Alexander Nozdrin authored
-
- 23 Nov, 2009 6 commits
-
-
Konstantin Osipov authored
-
Konstantin Osipov authored
------------------------------------------------------------- revno: 2877 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 35164-6.0 timestamp: Wed 2008-10-15 19:53:18 -0300 message: Bug#35164: Large number of invalid pthread_attr_setschedparam calls Bug#37536: Thread scheduling causes performance degradation at low thread count Bug#12702: Long queries take 100% of CPU and freeze other applications under Windows The problem is that although having threads with different priorities yields marginal improvements [1] in some platforms [2], relying on some statically defined priorities (QUERY_PRIOR and WAIT_PRIOR) to play well (or to work at all) with different scheduling practices and disciplines is, at best, a shot in the dark as the meaning of priority values may change depending on the scheduling policy set for the process. Another problem is that increasing priorities can hurt other concurrent (running on the same hardware) applications (such as AMP) by causing starvation problems as MySQL threads will successively preempt lower priority processes. This can be evidenced by Bug#12702. The solution is to not change the threads priorities and rely on the system scheduler to perform its job. This also enables a system admin to increase or decrease the scheduling priority of the MySQL process, if intended. Furthermore, the internal wrappers and code for changing the priority of threads is being removed as they are now unused and ancient. 1. Due to unintentional side effects. On Solaris this could artificially help benchmarks as calling the priority changing syscall millions of times is more beneficial than the actual setting of the priority. 2. Where it actually works. It has never worked on Linux as the default scheduling policy SCHED_OTHER only accepts the static priority 0. configure.in: Remove checks for functions that are not used anymore. include/config-netware.h: Remove unused define. include/my_pthread.h: Remove thread priority changing wrappers. mysys/my_pthread.c: Remove thread priority changing wrappers. They do not work properly and their implementations were incorrectly protected by a check for HAVE_PTHREAD_SETSCHEDPARAM. mysys/thr_alarm.c: Remove meaningless (100) increase of a thread priority. sql/mysql_priv.h: Remove meaningless thread priority values. sql/mysqld.cc: Don't change thread priorities. sql/slave.cc: Don't change thread priorities. sql/slave.h: Update function prototype. sql/sql_parse.cc: Don't change thread priorities. sql/sql_prepare.cc: Don't change thread priorities. sql/unireg.h: Mark flag as obsolete. storage/innobase/handler/ha_innodb.cc: Remove use of obsolete flag and associated behavior. storage/innobase/include/srv0srv.h: Remove use of obsolete flag and associated variables. storage/innobase/os/os0thread.c: Remove use of obsolete flag and associated behavior. storage/innobase/srv/srv0srv.c: Remove use of obsolete flag and associated variables.
-
Horst.Hunger authored
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2630.13.2 committer: Davi Arnaut <davi@sun.com> branch nick: WL4284-6.0 timestamp: Thu 2008-07-03 18:26:51 -0300 message: Remove unused USING_TRANSACTIONS macro which unnecessarily cumbers the code. This macro is a historical leftover and has no practical use since its unconditionally defined. sql/handler.cc: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/handler.h: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/log.cc: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/log_event.cc: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/set_var.cc: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/sql_class.cc: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/sql_class.h: Remove an always defined #ifdef (USING_TRNASACTIONS). sql/sql_parse.cc: Remove an always defined #ifdef (USING_TRNASACTIONS).
-
Alexander Nozdrin authored
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2642 committer: davi@mysql.com/endora.local timestamp: Fri 2008-05-16 01:29:09 -0300 message: Fix for a valgrind warning due to a jump on a uninitialized variable. The problem was that the sql profile preparation function wasn't being called for all possible code paths of query execution. The solution is to move the preparation to the dispatch_command function and to explicitly call the profile preparation function on bootstrap.
-
- 22 Nov, 2009 1 commit
-
-
Luis Soares authored
beyond unsigned long. BUG#44779: binlog.binlog_max_extension may be causing failure on next test in PB NOTE1: this is the backport to next-mr. NOTE2: already includes patch for BUG#44779. Binlog file extensions would turn into negative numbers once the variable used to hold the value reached maximum for signed long. Consequently, incrementing value to the next (negative) number would lead to .000000 extension, causing the server to fail. This patch addresses this issue by not allowing negative extensions and by returning an error on find_uniq_filename, when the limit is reached. Additionally, warnings are printed to the error log when the limit is approaching. FLUSH LOGS will also report warnings to the user, if the extension number has reached the limit. The limit has been set to 0x7FFFFFFF as the maximum. mysql-test/suite/binlog/t/binlog_max_extension.test: Test case added that checks the maximum available number for binlog extensions. sql/log.cc: Changes to find_uniq_filename and test_if_number. sql/log.h: Added macros with values for MAX_LOG_UNIQUE_FN_EXT and LOG_WARN_UNIQUE_FN_EXT_LEFT, as suggested in review.
-