Remove some more leftovers from the initial removal:
o Update relevant mentions of configure.in throughout
the source code.
o Remove win/configure.js, which at this point just
duplicates logic already present in CMake based build
system.
o Remove support files which relied on the autotools
build system. In any case, MySQL is no longer officially
supported on SCO.
o Remove files which are no longer part of the build.
The autotools-based build system has been superseded and
is being removed in order to ease the maintenance burden on
developers tweaking and maintaining the build system.
In order to support tools that need to extract the server
version, a new file that (only) contains the server version,
called VERSION, is introduced. The file contents are human
and machine-readable. The format is:
MYSQL_VERSION_MAJOR=5
MYSQL_VERSION_MINOR=5
MYSQL_VERSION_PATCH=8
MYSQL_VERSION_EXTRA=-rc
The CMake based version extraction in cmake/mysql_version.cmake
is changed to extract the version from this file. The configure
to CMake wrapper is retained for backwards compatibility and to
support the BUILD/ scripts. Also, a new a makefile target
show-dist-name that prints the server version is introduced.
Memory was allocated for storing path names inside
fn_expand(), which were not free:ed anywhere.
This patch fixes the problem by storing the path
names in statically allocated buffers instead,
which is automatically free:ed when the server
exits.
Before this fix, file io for the binary log file was not accounted properly,
and showed no io at all.
This bug was due to the following issues:
1) file io for the binlog was instrumented:
- sometime as "wait/io/file/sql/binlog"
- sometime as "wait/io/file/sql/MYSQL_LOG"
leading to inconsistent event_names.
2) the binlog file itself was using an IO_CACHE,
but the IO_CACHE implementation in mysys/mf_iocache.c was
not instrumented to make performance schema calls to record file io.
3) The "wait/io/file/sql/MYSQL_LOG" instrumentation was used
for several log files, such as:
- the binary log
- the slow log
- the query log
which caused file io in these different log files to be accounted
against the same instrument.
The instrumentation needs to have a finer grain and report io
in different event_names, because each file really serves a different purpose.
With this fix:
- the IO_CACHE implementation is now instrumented
- the "wait/io/file/sql/MYSQL_LOG" instrument has been removed
- binlog io is now always instrumented with "wait/io/file/sql/binlog"
- the slow log is instrumented with a new name, "wait/io/file/sql/slow_log"
- the query log is instrumented with a new name, "wait/io/file/sql/query_log"
GCOV builds were broken after the patch for Bug#57933
which added add -Wdeclaration-after-statement to gcc builds.
This patch fixes:
stacktrace.c:328: warning: ISO C90 forbids mixed
declarations and code
No test case added.
GCOV builds were broken after the patch for Bug#57933
which added add -Wdeclaration-after-statement to gcc builds.
This patch fixes:
stacktrace.c:328: warning: ISO C90 forbids mixed
declarations and code
No test case added.
If a relative path is supplied to option --defaults-file or
--defaults-extra-file, the server will crash when executing
an INSTALL PLUGIN command. The reason is that the defaults
file is initially read relative the current working directory
when the server is started, but when INSTALL PLUGIN is executed,
the server has changed working directory to the data directory.
Since there is no check that the call to my_load_defaults()
inside mysql_install_plugin(), the subsequence call to
free_defaults() will crash the server.
This patch fixes the problem by:
- Prepending the current working directory to the file name when
a relative path is given to the --defaults-file or --defaults-
extra-file option the first time my_load_defaults() is called,
which is just after the server has started in main().
- Adding a check of the return value of my_load_defaults() inside
mysql_install_plugin() and aborting command (with an error) if
an error is returned.
- It also adds a check of the return value for load_defaults in
lib_sql.cc for the embedded server since that was missing.
To test that the relative files for the options --defaults-file and
--defaults-extra-file is handled properly, mysql-test-run.pl is also
changed to not add a --defaults-file option if one is provided in the
tests *.opt file.
Boolean options cause parsing failures when they are given
with prefix loose- and an argument, either in the command
line or in configuration file.
The reason was a faulty logic which forced the parsing
to throw an error when an argument of type NO_ARG was
used together with an argument which has been identified
as a key-value pair. Despite the attribute NO_ARG these
options actually take arguments if they are of type
BOOL.
Ensure that fdatasync is properly declared as on Mac OS X, the
function is available but there is no prototype. Also, port a
fix for a warning from the InnoDB plugin over to the builtin.
Where realpath(3) is used in Linux, mf_load_path is
used for Windows. This function doesn't however
correspond to the functionality of realpath.
This patch attempts to do better by using
the Windows function GetFullPathName() instead.
error flushing io cache
The reason for the error was incorrect return code from
my_win_write() in case of error on 64 bit Windows.
Error should be indicated by return code
(size_t)-1 == 2^64 -1, but due to cast it was
(DWORD)-1 = 2^32 -1
The caller of this function would fail to recognize the error
and continue looping.
Fix is to return correct error code (size_t)-1 in case of error
as expected by caller.
Also minimal cleanup is done : my_win_write() now uses
the same parameter checks as related functions (0 and
overflow handling for count parameter).
detector". This patch addresses performance regression in OLTP_RO/MyISAM
test on Windows introduced by the fix for bug #56405. Thus it makes
original patch acceptable as a solution for bug #56585 "Slowdown of
readonly sysbench benchmarks (e.g point_select) on Windows 5.5".
With this patch, MySQL will use native Windows condition variables and
reader-writer locks if they are supported by the OS.
This speeds up MyISAM and the effect comes mostly from using native
rwlocks. Native conditions improve scalability with higher number of
concurrent users in other situations, e.g for prlocks.
Benchmark numbers for this patch as measured on Win2008R2 quad
core machine are attached to the bug report.
( direct link http://bugs.mysql.com/file.php?id=15883 )
Note that currently we require at least Windows7/WS2008R2 for
reader-writer locks, even though native rwlock is available also on Vista.
Reason is that "trylock" APIs are missing on Vista, and trylock is used in
the server (in a single place in query cache).
While this patch could have been written differently, to enable the native
rwlock optimization also on Vista/WS2008 (e.g using native locks everywhere
but portable implementation in query cache), this would come at the
expense of the code clarity, as it would introduce a new "try-able" rwlock
type, to handle Vista case.
Another way to improve performance for the special case
(OLTP_RO/MYISAM/Vista) would be to eliminate "trylock" usage from server,
but this is outside of the scope here.
Native conditions variables are used beginning with Vista though the effect
of using condition variables alone is not measurable in this benchmark.
But when used together with native rwlocks on Win7, native conditions improve
performance in high-concurrency OLTP_RO/MyISAM (128 and more sysbench
users).
detector" that doesn't introduce bug #56715 "Concurrent
transactions + FLUSH result in sporadical unwarranted
deadlock errors".
Deadlock could have occurred when workload containing a mix
of DML, DDL and FLUSH TABLES statements affecting the same
set of tables was executed in a heavily concurrent environment.
This deadlock occurred when several connections tried to
perform deadlock detection in the metadata locking subsystem.
The first connection started traversing wait-for graph,
encountered a sub-graph representing a wait for flush, acquired
LOCK_open and dived into sub-graph inspection. Then it
encountered sub-graph corresponding to wait for metadata lock
and blocked while trying to acquire a rd-lock on
MDL_lock::m_rwlock, since some,other thread had a wr-lock on it.
When this wr-lock was released it could have happened (if there
was another pending wr-lock against this rwlock) that the rd-lock
from the first connection was left unsatisfied but at the same
time the new rd-lock request from the second connection sneaked
in and was satisfied (for this to be possible the second
rd-request should come exactly after the wr-lock is released but
before pending the wr-lock manages to grab rwlock, which is
possible both on Linux and in our own rwlock implementation).
If this second connection continued traversing the wait-for graph
and encountered a sub-graph representing a wait for flush it tried
to acquire LOCK_open and thus the deadlock was created.
The previous patch tried to workaround this problem by not
allowing the deadlock detector to lock LOCK_open mutex if
some other thread doing deadlock detection already owns it
and current search depth is greater than 0. Instead deadlock
was reported. As a result it has introduced bug #56715.
This patch solves this problem in a different way.
It introduces a new rw_pr_lock_t implementation to be used
by MDL subsystem instead of one based on Linux rwlocks or
our own rwlock implementation. This new implementation
never allows situation in which an rwlock is rd-locked and
there is a blocked pending rd-lock. Thus the situation which
has caused this bug becomes impossible with this implementation.
Due to fact that this implementation is optimized for
wr-lock/unlock scenario which is most common in the MDL
subsystem it doesn't introduce noticeable performance
regressions in sysbench tests. Moreover it significantly
improves situation for POINT_SELECT test when many
connections are used.
No test case is provided as this bug is very hard to repeat
in MTR environment but is repeatable with the help of RQG
tests.
This patch also doesn't include a test for bug #56715
"Concurrent transactions + FLUSH result in sporadical
unwarranted deadlock errors" as it takes too much time to
be run as part of normal test-suite runs.
Before this fix, the server did not recognize 'short' (as in -a)
options but only 'long' (as in --ansi) options
in the startup command line, due to earlier changes in 5.5
introduced for the performance schema.
The root cause is that handle_options() did not honor the
my_getopt_skip_unknown flag when parsing 'short' options.
The fix changes handle_options(), so that my_getopt_skip_unknown is
honored in all cases.
Note that there are limitations to this,
see the added doxygen documentation in handle_options().
The current usage of handle_options() by the server to
parse early performance schema options fits within the limitations.
This has been enforced by an assert for PARSE_EARLY options, for safety.
my_thread_global_end() now sets mysql_thread_basic_global_init_done= 0
to ensure destroyed mutexes are not reused.
I verified that clearing this flag will not result in the redundant allocation
of other resources allocated by my_thread_global_init() and
my_thread_basic_global_init().
Use UNINIT_VAR workaround instead of LINT_INIT. The former can
also be used to silence false-positives in non-debug builds as
it actually does not cause new code to be generated.