- 20 Dec, 2009 3 commits
-
-
Vladislav Vaintroub authored
It was pthread_mutex_t in mi_static.c and mysql_mutex_t in my_thr_init.c Solaris linker complains about different size of the symbol.
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
- 19 Dec, 2009 14 commits
-
-
Vladislav Vaintroub authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Vladislav Vaintroub authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
Post-merge fix: wait for statement result before disconnecting. Otherwise the statement might affect unrelated tests. mysql-test/t/lock_multi.test, Reap statement status
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
-
- 18 Dec, 2009 5 commits
-
-
Vladislav Vaintroub authored
-
Alfranio Correia authored
Updated suppressed warning messages.
-
Mikael Ronstrom authored
-
Mikael Ronstrom authored
Added extra checks of 64-bit atomic support on GCC and Solaris, also added 64-bit support in solaris.h which was missing
-
Vladislav Vaintroub authored
-
- 17 Dec, 2009 16 commits
-
-
Vladislav Vaintroub authored
-
Alexander Nozdrin authored
Conflicts: - mysys/charset.c - mysys/my_thr_init.c
-
Alexander Nozdrin authored
Conflicts: - storage/myisam/mi_packrec.c
-
Alexey Kopytov authored
-
Alfranio Correia authored
-
Alexey Kopytov authored
-
Andrei Elkin authored
-
Andrei Elkin authored
The test allowed random coincidence of connection ids for two concurrent sessions performing CREATE/DROP temp tables. Fixed with correcting the test. The sessions connection ids are not changed from their defaults anymore.
-
Vladislav Vaintroub authored
MYSQL_ADD_EXECUTABLE will instructs CPack where to install the exe. On Windows, it also adds version resource and if -DSIGNCODE was given, will sign the exe in packaging step.
-
Satya B authored
-
Satya B authored
-
Satya B authored
When compressed myisam files are opened, they are always memory mapped sometimes causing memory swapping problems. When we mmap the myisam compressed tables of size greater than the memory available, the kswapd0 process utilization is very high consuming 30-40% of the cpu. This happens only with linux kernels older than 2.6.9 With newer linux kernels, we don't have this problem of high cpu consumption and this option may not be required. The option 'myisam_mmap_size' is added to limit the amount of memory used for memory mapping of myisam files. This option is not dynamic. The default value on 32 bit system is 4294967295 bytes and on 64 bit system it is 18446744073709547520 bytes. Note: Testcase only tests the option variable. The actual bug has be to tested manually.
-
Martin Hansson authored
returns incorrect results with where An outer join of a const table (outer) and a normal table (inner) with GROUP BY on a field from the outer table would optimize away GROUP BY, and thus trigger the optimization to do away with a temporary table if grouping was performed on columns from the const table, hence executing the query with filesort without temporary table. But this should not be done if there is a non-indexed access to the inner table, since filesort does not handle joins. It expects either ref access, range ditto or table scan. The join condition will thus not be applied. Fixed by always forcing execution with temporary table in the case of ROLLUP with a query involving an outer join. This is a slightly broader class of queries than need fixing, but it is hard to ascertain the position of a ROLLUP field wrt outer join with current query representation.
-
Marc Alff authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
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.
-
- 16 Dec, 2009 2 commits
-
-
Marc Alff authored
-
Magne Mahre authored
The bug is caused by a race condition between the INSERT DELAYED thread and the client thread's FLUSH TABLE. The FLUSH TABLE does not guarantee (as is (wrongly) suggested in the test case) that the INSERT DELAYED is ever executed. The execution of the test case will thus not be deterministic. The fix has been to do a deterministic verification that both threads are complete by checking the content of the table.
-