- 21 Sep, 2007 1 commit
-
-
iggy@alf.(none) authored
make sure that if builder configured with a non-standard (!= 3306) default TCP port that value actually gets used throughout.
-
- 13 Sep, 2007 1 commit
-
-
make sure that if builder configured with a non-standard (!= 3306) default TCP port that value actually gets used throughout. if they didn't configure a value, assume "use a sensible default", which will be read from /etc/services or, failing that, from the factory default. That makes the order of preference - command-line option - my.cnf, where applicable - $MYSQL_TCP_PORT environment variable - /etc/services (unless configured --with-tcp-port) - default port (--with-tcp-port=... or factory default)
-
- 20 Jul, 2007 1 commit
-
-
Result adjusted.
-
- 19 Jul, 2007 3 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/50
-
- 18 Jul, 2007 1 commit
-
-
cmiller@zippy.cornsilk.net authored
when creating table Federated tables had an artificially low maximum of key length, because the handler failed to implement a method to return it and the default value is taked from the prototype handler. Now, implement that method and return the maximum possible key length, which is that of InnoDB.
-
- 17 Jul, 2007 5 commits
-
-
dkatz@damien-katzs-computer.local authored
Fixed the yassl base64 decoding to correctly allocate a maximum decoded buffer size.
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/maint/50
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
tnurnberg@sin.intern.azundris.com authored
into sin.intern.azundris.com:/home/tnurnberg/27198/50-27198
-
tnurnberg@sin.intern.azundris.com authored
into sin.intern.azundris.com:/home/tnurnberg/27198/50-27198
-
- 16 Jul, 2007 5 commits
-
-
tnurnberg@sin.intern.azundris.com authored
into sin.intern.azundris.com:/home/tnurnberg/27198/41-27198
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
selected prior: ensure the fix also works for information_schema tables.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
-
- 15 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
Linux Debug build (possible deadlock)" The bug is not repeatable any more.
-
- 14 Jul, 2007 4 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
svoj@mysql.com/april.(none) authored
pseudo_thread_id was reset to zero via mysql_change_user() handling whereas there is no reason to do that. Moreover, having two concurrent threads that change user and create a namesake temp tables leads to recording the dup pair of queries: set @@session.pseudo_thread_id = 0; CREATE temporary table `the namesake`; which will stall the slave as the second instance can not be created. And that is the bug case. Fixed by correcting pseudo_thread_id value after mysql_change_user().
-
- 13 Jul, 2007 7 commits
-
-
tnurnberg@sin.intern.azundris.com authored
gettimeofday() can fail and presumably, so can time(). Keep an eye on it. Since we have no data on this at all so far, we just retry on failure (and log the event), assuming that this is just an intermittant failure. This might of course hang the threat until we succeed. Once we know more about these failures, an appropriate more clever scheme may be picked (only try so many times per thread, etc., if that fails, return last "good" time() we got or some such). Using sql_print_information() to log as this probably only occurs in high load scenarios where the debug- trace likely is disabled (or might interfere with testing the effect). No test-case as this is a non-deterministic issue.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-maint
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
dkatz@damien-katzs-computer.local authored
When opening a new connecgtion, changed mysqltest to prefer a brand new connection slot over an existing, closed slot. Fixes a problem with reused slots that can cause tests to fail. bug#29579
-
dkatz@damien-katzs-computer.local authored
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/50
-
dkatz@damien-katzs-computer.local authored
Added an option to yassl to allow "quiet shutdown" like openssl does. This option causes the SSL libs to NOT perform the close_notify handshake during shutdown. This fixes a hang we experience because we hold a lock during socket shutdown.
-
- 12 Jul, 2007 7 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
incomplete in 5.0 (and review fixes). When in 5.0.13 I introduced class Prepared_statement and methods ::prepare and ::execute, general logging was left out of this class. This was good for stored procedures, since in stored procedures we do not log sub-statements, but introduced a regression in case of SQL syntax for prepared statements, as previously we would log the actual statements to the log, and after the change we would log only COM_QUERY text. Restore the old behavior, but still suppress logging if inside a stored procedure. Based on a community contributed patch from Vladimir Shebordaev. No test case since we do not have a mechanism to test output of the general log.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-26141-final
-
kostja@bodhi.(none) authored
causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
A race condition in the integration between MyISAM and the query cache code caused the query cache to fail to invalidate itself on concurrently inserted data. This patch fix this problem by using the existing handler interface which, upon each statement cache attempt, compare the size of the table as viewed from the cache writing thread and with any snap shot of the global table state. If the two sizes are different the global table size is unknown and the current statement can't be cached.
-
- 11 Jul, 2007 3 commits
-
-
kostja@bodhi.(none) authored
Fix the parser to make the database options not optional.
-
kaa@polly.local authored
into polly.local:/home/kaa/src/maint/mysql-5.0-maint
-
kaa@polly.local authored
In case of out-of-memory error received from the master, print the corresponding message to the error log and stop slave I/O thread to avoid reconnecting with a wrong binary log position.
-
- 10 Jul, 2007 1 commit
-
-
tnurnberg@sin.intern.azundris.com authored
into mysql.com:/home/tnurnberg/22540/50-22540
-