- 25 Nov, 2009 2 commits
-
-
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
-
- 24 Nov, 2009 5 commits
-
-
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).
-
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 5 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.
-
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.
-
- 21 Nov, 2009 1 commit
-
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2627 committer: davi@mysql.com/endora.local timestamp: Wed 2008-04-23 13:25:02 -0300 message: Fix for a build failure on Windows due to ssize_t not being declared.
-
- 20 Nov, 2009 10 commits
-
-
Konstantin Osipov authored
Original changeset: ------------------------------------------------------------ revno: 2626 committer: davi@mysql.com/endora.local timestamp: Wed 2008-04-23 09:33:25 -0300 message: Fix for main.ssl and main.ssl_compress test case failures under pool-of-threads. The problem is that the SSL layer has a read buffer and might read more data than requested by the VIO layer. The SSL layer empties the socket buffer which causes the socket to not be signaled for IO if the client is waiting for a command which is sitting in the read buffer. The solution is to retrieve from the transport layer the number of bytes waiting in the read buffer. The data in the read buffer needs to be processed before waiting for more data.
-
Konstantin Osipov authored
inside a stored routine" from 6.0-codebase.
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2597.42.4 committer: davi@mysql.com/endora.local timestamp: Tue 2008-04-15 17:29:42 -0300 message: Bug#36004 mysql_stmt_prepare resets the list of warnings Although the manual says that "the list of messages is reset for each new statement that uses a table", the list of messages is being unconditionally reset for prepare commands. The solution is to enforce that the prepare command will only reset the message list if the statement being prepared uses a table or a warning is pushed. tests/mysql_client_test.c: Add test case for Bug#36004
-
Konstantin Osipov authored
mysql-test/t/sp-error.test: Backport test of Bug#36510 (the bug itself is fixed by other backports, inc. SINGAL code).
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2572.23.1 committer: davi@mysql.com/endora.local timestamp: Wed 2008-03-19 09:03:08 -0300 message: Bug#17954 Threads_connected > Threads_created The problem is that insert delayed threads are counted as connected but not as created, leading to a Threads_connected value greater then the Threads_created value. The solution is to enforce the documented behavior that the Threads_connected value shall be the number of currently open connections and that Threads_created shall be the number of threads created to handle connections. mysql-test/r/status.result: Add test case result for Bug#17954 mysql-test/t/status.test: Add test case for Bug#17954 sql/mysqld.cc: Change Threads_connected to reflect the number of open connections. SHOW_INT type variables are not reset.
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2476.1116.1 committer: davi@mysql.com/endora.local timestamp: Fri 2007-12-14 10:10:19 -0200 message: DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES WITH READ LOCK (global read lock) can lead to a deadlock. The solution is to not wait for the global read lock if the thread is holding any locked tables. Related to bugs 23713 and 32395. This issues is being fixed only on 6.0 because it depends on the fix for bug 25858 -- which was fixed only on 6.0.
-
Konstantin Osipov authored
------------------------------------------------------------ revno: 2476.784.3 committer: davi@moksha.local timestamp: Tue 2007-10-02 21:27:31 -0300 message: Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks When a client (connection) holds a lock on a table and attempts to drop (obtain a exclusive lock) on a second table that is already held by a second client and the second client then attempts to drop the table that is held by the first client, leads to a circular wait deadlock. This scenario is very similar to trying to drop (or rename) a table while holding read locks and are correctly forbidden. The solution is to allow a drop table operation to continue only if the table being dropped is write (exclusively) locked, or if the table is temporary, or if the client is not holding any locks. Using this scheme prevents the creation of a circular chain in which each client is waiting for one table that the next client in the chain is holding. This is incompatible change, as can be seen by number of tests cases that needed to be fixed, but is consistent with respect to behavior of the different scenarios in which the circular wait might happen. mysql-test/r/drop.result: Test case result for Bug#25858 mysql-test/r/group_by.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/insert_notembedded.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table mysql-test/r/lock.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/lock_multi.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/myisam.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/view.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/t/drop.test: Add test case for Bug#25858 mysql-test/t/group_by.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/insert_notembedded.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/lock.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/lock_multi.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/myisam.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/query_cache_notembedded.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/view.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. sql/lock.cc: When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.
-
Konstantin Osipov authored
revno: 2476.784.2 committer: davi@moksha.local timestamp: Thu 2007-09-27 16:56:27 -0300 message: Bug#28870 check that table locks are released/reset The problem is that some mysql_lock_tables error paths are not resetting the tables lock type back to TL_UNLOCK. If the lock types are not reset properly, a table might be returned to the table cache with wrong lock_type. The proposed fix is to ensure that the tables lock type is always properly reset when mysql_lock_tables fails. This is a incompatible change with respect to the process state information. sql/lock.cc: Merge mysql_lock_tables cleanup sequence and the reset_lock_data function into a single function and take steps to ensure it is always called for each error exit path. Also remove references to the redundant THD::locked variable which was almost exclusively used by this function and the same information is already on proc_info. sql/sql_class.cc: Remove references to the THD::locked variable. sql/sql_class.h: Remove the THD::locked variable. sql/sql_show.cc: Remove references to THD:locked, state_info will now default to proc_info.
-
Marc Alff authored
-
Magne Mahre authored
-
- 19 Nov, 2009 1 commit
-
-
Davi Arnaut authored
-
- 18 Nov, 2009 4 commits
- 16 Nov, 2009 2 commits
- 13 Nov, 2009 1 commit
-
-
Davi Arnaut authored
mysql-test/r/sp-error.result: Update test case result. mysql-test/t/dirty_close.test: Dirty close does not work under embedded. mysql-test/t/sp-error.test: Use the specific error number so it won't catch other non-fatal errors.
-
- 12 Nov, 2009 6 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 11 Nov, 2009 3 commits
-
-
Magne Mahre authored
Just change mysql_foo to mysql_cv_foo for one cache-id variable name. There was only one bad variable name, present in 5.0 and 5.1, but not in the -pe branch. Backported to 5.6.0 (mysql-next-mr-runtime)
-
Magne Mahre authored
STRING_RESULT argument There is a "magic" number for precision : NOT_FIXED_DEC. This means that the precision is not a fixed number. But this constant was re-defined in several files and was not available to the UDF developers. Moved the NOT_FIXED_DEC definition to the correct header and removed the redundant definitions. Backported to 5.6.0 (mysql-next-mr-runtime) client/sql_string.h: moved NOT_FIXED_DEC to the correct header include/mysql_com.h: moved NOT_FIXED_DEC to the correct header libmysql/libmysql.c: moved NOT_FIXED_DEC to the correct header sql/field.h: moved NOT_FIXED_DEC to the correct header sql/sql_string.h: moved NOT_FIXED_DEC to the correct header storage/ndb/include/kernel/signaldata/DictTabInfo.hpp: moved NOT_FIXED_DEC to the correct header
-
Magne Mahre authored
Add result file format v2 Backport to 5.6.0
-