----------------------------------------------------------
revno: 2630.28.1
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Thu 2008-10-23 15:23:44 +0400
message:
Bug#32738 "mysqld: Two slow log option/variable descriptions are
inaccurate"
Update option description per suggestion from the documentation team.
not on predefined values
The default name of the PID file was constructed, as documented,
based on the hostname. This name was subsequently used as the
base for the general log file name. If the name of the PID
file was overridden in the configuration, and no explicit name
was set for the general log file, the path location for the
PID file was used also for the general log file.
A new variable, 'default_logfile_name', has been introduced. This name
is constructed based on the hostname, and is then used to
construct both the PID file and the general log file.
The general log file will now, unless explicitly set, be
located in the server data directory (as documentated in
the server docs)
"have_profiling"
1) Renamed have_community_features server system variable to
have_profiling.
2) Removed eable-community-features configure option and
ENABLE_COMMUNITY_FEATURES macro.
3) Removed COMMUNITY_SERVER macro and replaced its usage by
ENABLED_PROFILING.
Only --enable-profiling is now needed to enable profiling.
It was the only existing "community feature", so there was
no need for both configure options.
Using --enable-community-features will give a warning message
since it no longer exists.
revno: 2476.785.24
committer: kostja@bodhi.(none)
timestamp: Tue 2007-10-16 20:19:00 +0400
message:
Reflect a rename of a member in the client ABI (a compatible change).
----------------------------------------------------------
revno: 2476.423.26
committer: kostja@bodhi.(none)
timestamp: Tue 2007-10-16 20:12:37 +0400
message:
Update the client ABI to reflect member rename
(this is a backward-compatible change).
----------------------------------------------------------
revno: 2476.785.22
committer: kostja@bodhi.(none)
timestamp: Tue 2007-10-16 19:37:25 +0400
message:
Remove some remains of support of 3.22 protocol. This was in fact dead code,
since the option to talk 3.22 protocol was removed in 4.1 and there
is no other protocol negotiation mechanism besides this option.
http://lists.mysql.com/commits/59686
Cleanup pthread_self(), pthread_create(), pthread_join() implementation on Windows.
Prior implementation is was unnecessarily complicated and even differs in embedded
and non-embedded case.
Improvements in this patch:
* pthread_t is now the unique thread ID, instead of HANDLE returned by beginthread
This simplifies pthread_self() to be just straight GetCurrentThreadId().
prior it was much art involved in passing the beginthread() handle from the caller
to the TLS structure in the child thread ( did not work for the main thread of
course)
* remove MySQL specific my_thread_init()/my_thread_end() from pthread_create.
No automagic is done on Unix on pthread_create(). Having the same on Windows will
improve portability and avoid extra #ifdef's
* remove redefinition of getpid() - it was defined as GetCurrentThreadId()
"Patch to fix bug 38551": it was a manual backport (2008-10-15) of
http://lists.mysql.com/commits/56418.
But that was an early, non-final patch from the fixer of this bug (TheK):
after that backport was made by Mikael, TheK decided to do a different fix,
which was finally pushed into 6.0.
Then 5.1's code was changed for some other reasons, so now we have a
conflict between the old never-approved TheK patch backported to Summit and
the latest 5.1. The backport cannot stay, it has to be removed due to
the conflict, and then rewritten if desired.
bzr branch mysql-5.1-performance-version mysql-trunk # Summit
cd mysql-trunk
bzr merge mysql-5.1-innodb_plugin # which is 5.1 + Innodb plugin
bzr rm innobase # remove the builtin
Next step: build, test fixes.
- Define and pass compile time path variables as pre-processor definitions to
mimic the makefile build.
- Set new CMake version and policy requirements explicitly.
- Changed DATADIR to MYSQL_DATADIR to avoid conflicting definition in
Platform SDK header ObjIdl.h which also defines DATADIR.
Initialize LOCK_open as a adapative mutex on platforms where the
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP macro is available. The flag
indicates that a thread should spin (busy wait) for some time on a
locked adaptive mutex before blocking (sleeping). It's intended to
to alleviate performance problems due to LOCK_open being a highly
contended mutex.
The maximum value of the max_join_size variable is set by converting
a signed type (long int) with negative value (-1) to a wider unsigned
type (unsigned long long), which yields the largest possible value of
the wider unsigned type -- as per the language conversion rules. But,
depending on build options, the type of the max_join_size might be a
shorter type (ha_rows - unsigned long) which causes the warning to be
thrown once the large value is truncated to fit.
The solution is to ensure that the maximum value of the variable is
always set to the maximum value of integer type of max_join_size.
Furthermore, it would be interesting to always have a fixed type for
this variable, but this would incur in a change of behavior which is
not acceptable for a GA version. See Bug#35346.
not logged
Errors encountered during initialization of the SSL subsystem
are printed to stderr, rather than to the error log.
This patch adds a parameter to several SSL init functions to
report the error (if any) out to the caller. The function
init_ssl() in mysqld.cc is moved after the initialization of
the log subsystem, so that any error messages can be logged to
the error log. Printing of messages to stderr has been
retained to get diagnostic output in a client context.
The reason for the crash was rotate_relay_log (mi=0x0) did not verify
the passed value of active_mi. There are more cases where active_mi
is supposed to be non-zero e.g change_master(), stop_slave(), and it's
reasonable to protect from a similar crash all of them with common
fixes.
Fixed with spliting end_slave() in slave threads release and slave
data clean-up parts (a new close_active_mi()). The new function is
invoked at the very end of close_connections() so that all users of
active_mi are proven to have left.
The problem: described in the bug report.
The fix:
--increase buffers where it's necessary
(buffers which are used in stxnmov)
--decrease buffer lengths which are used
variable. The problem was that THD::connect_utime could be
used without being initialized when the main thread is used
to handle connections (--thread-handling=no-threads).
always rollsback.
There is failure on pushbuild machines which are using old compilers complaining about
ULLONG_MAX declaration. Changing this to ULONGLONG_MAX to solve the problem.
always rollsback.
The global variable max_binlog_cache_size cannot be set more than 4GB on
32 bit systems, limiting transactions of all storage engines to 4G of changes.
The problem is max_binlog_cache_size is declared as ulong which is 4 bytes
on 32 bit and 8 bytes on 64 bit machines.
Fixed by using ulonglong for max_binlog_cache_size which is 8bytes on 32
and 64 bit machines.The range for max_binlog_cache_size on 32 bit and 64 bit
systems is 4096-18446744073709547520 bytes.
for indexes of InnoDB table
Fixes by replacing the PRNG that is used to pick random pages with a
better one.
Also adds a configuration option "innodb_use_legacy_cardinality_algorithm"
to enable the fix only when the option is set.
This patch is from http://bugs.mysql.com/file.php?id=11789
The problem is that creating a event could fail if the value of
the variable server_id didn't fit in the originator column of
the event system table. The cause is two-fold: it was possible
to set server_id to a value outside the documented range (from
0 to 2^32-1) and the originator column of the event table didn't
have enough room for values in this range.
The log tables (general_log and slow_log) also don't have a proper
column type to store the server_id and having a large server_id
value could prevent queries from being logged.
The solution is to ensure that all system tables that store the
server_id value have a proper column type (int unsigned) and that
the variable can't be set to a value that is not within the range.