- 02 Aug, 2007 3 commits
-
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/cmake-tls/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
Aligned client library build and use with the Unix version when it comes to what source to include directly in the builds, and what libraries to link with (bug#30118). Also reviewed, corrected and made more clear when static or dynamic Thread Local Storage is to be used. Some code duplication was removed, and some redundant library usage were removed, reducing the risk of incorrect TLS usage.
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
- 01 Aug, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 31 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
- 30 Jul, 2007 7 commits
-
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/config_h/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
to "my_config.h". Not to pollute the top directory, and to get more control over what is included. Made the include path for "libedit" pick up its own "config.h" first.
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/config_h/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
Backport of correction for Mac OS X build problem, global variable not initiated is "common" and can't be used in shared libraries, unless special flags are used (bug#26218)
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp3/mysql-5.0-build
-
kostja@bodhi.(none) authored
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
- 29 Jul, 2007 1 commit
-
-
thek@adventure.(none) authored
- Removed unused variable.
-
- 27 Jul, 2007 9 commits
-
-
jperkin@production.mysql.com authored
into production.mysql.com:/usersnfs/jperkin/bk/mysql-5.0
-
jperkin@production.mysql.com authored
into production.mysql.com:/usersnfs/jperkin/bk/mysql-5.0
-
kent@mysql.com/kent-amd64.(none) authored
Moved CERT files to where they are used, avoids conflict between two make files trying to install the same CERTs SSL/*.pem, Move: SSL/*.pem -> mysql-test/std_data/
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
When a table was explicitly locked with LOCK TABLES no associated tables from any related trigger on the subject table were locked. As a result of this the user could experience unexpected locking behavior and statement failures similar to "failed: 1100: Table'xx' was not locked with LOCK TABLES". This patch fixes this problem by making sure triggers are pre-loaded on any statement if the subject table was explicitly locked with LOCK TABLES.
-
jperkin@production.mysql.com authored
- make the 'dist-hook' from top-level Makefile work again. - we can find my_print_defaults from --basedir by parsing command line arguments prior to running my_print_defaults. - take advantage of additional command line parsing and allow the --no-defaults etc arguments to work anywhere rather than having to be the first argument. - find SQL files either from binary archive or source install. - consolidate and tidy code and error messages.
-
kostja@bodhi.(none) authored
between perm and temp tables. Review fixes. The original bug report complains that if we locked a temporary table with LOCK TABLES statement, we would not leave LOCK TABLES mode when this temporary table is dropped. Additionally, the bug was escalated when it was discovered than when a temporary transactional table that was previously locked with LOCK TABLES statement was dropped, futher actions with this table, such as UNLOCK TABLES, would lead to a crash. The problem originates from incomplete support of transactional temporary tables. When we added calls to handler::store_lock()/handler::external_lock() to operations that work with such tables, we only covered the normal server code flow and did not cover LOCK TABLES mode. In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without matching ::external_lock(UNLOCK), e.g. when a transactional temporary table was dropped. Additionally, this table would be left in the list of LOCKed TABLES. The patch aims to address this inadequacy. Now, whenever an instance of 'handler' is destroyed, we assert that it was priorly external_lock(UNLOCK)-ed. All the places that violate this assert were fixed. This patch introduces no changes in behavior -- the discrepancy in behavior will be fixed when we start calling ::store_lock()/::external_lock() for all tables, regardless whether they are transactional or not, temporary or not.
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG29957/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
INSERT/DELETE/UPDATE followed by ALTER TABLE within LOCK TABLES may cause table corruption on Windows. That happens because ALTER TABLE writes outdated shared state info into index file. Fixed by removing obsolete workaround. Affects MyISAM tables on Windows only.
-
- 26 Jul, 2007 13 commits
-
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
For more information, see WL#3866 and the bugs numbered 28685 and 20390.
-
acurtis/antony@ltamd64.xiphis.org authored
into xiphis.org:/anubis/antony/work/mysql-5.0-engines.merge
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
into debian.(none):/M41/push-4.1
-
joerg@debian.(none) authored
into debian.(none):/M50/bug16635-5.0
-
jperkin@production.mysql.com authored
Fix error in previous change, correct --language argument.
-
jperkin@production.mysql.com authored
-
jperkin@production.mysql.com authored
available and reduce the chance of failure. This should fix bug#28585 which is caused by the script being quite random in how it finds files it requires and not giving very good feedback to the user about what went wrong. Also update make_binary_distribution so that it provides the correct path to the required SQL scripts when generating mysql_install_db. The script only previously worked because of the permissive behaviour which looked around the current working directory before the "correct" location. This could lead to severe problems if the user happened to run the script from a location which contained older or even broken copies of the SQL scripts. We now require either a complete binary release (and the mysql_install_db script ran from inside the extracted archive), or an installed compiled tree, as this is the only way we can be sure everything that we need is available and ready to run. While working on this fix, also clean up the mysql_install_db script a lot to make it simpler, easier to read, and hopefully less prone to bugs in the future.
-
joerg@debian.(none) authored
to 150 or 107 characters for those messages which are generated by the embedded server during release builds. This fixes bug#16635: Error messages wrong: absolute path names, "%s" format code See the bug report or the changelog for "sql/share/english/errmsg.txt" for instructions how to do that with other languages, even at the customer site, and for the restrictions to keep.
-
-
- 25 Jul, 2007 5 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
"Federated Denial of Service" Federated storage engine used to attempt to open connections within the ::create() and ::open() methods which are invoked while LOCK_open mutex is being held by mysqld. As a result, no other client sessions can open tables while Federated is attempting to open a connection. Long DNS lookup times would stall mysqld's operation and a rogue connection string which connects to a remote server which simply stalls during handshake can stall mysqld for a much longer period of time. This patch moves the opening of the connection much later, when the federated actually issues queries, by which time the LOCK_open mutex is no longer being held.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
anozdrin/alik@ibm. authored
binary SHOW CREATE TABLE or SELECT FROM I_S. The problem is that mysqldump generates incorrect dump for a table with non-ASCII column name if the mysqldump's character set is ASCII. The fix is to: 1. Switch character_set_client for the mysqldump's connection to binary before issuing SHOW CREATE TABLE statement in order to avoid conversion. 2. Dump switch character_set_client statements to UTF8 and back for CREATE TABLE statement.
-
anozdrin/alik@ibm. authored
This allows 5.0 to work with 5.1 databases.
-