- 29 Jan, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
The function that checks whether we can use keys for aggregates, find_key_for_maxmin(), assumes that keys disabled by ALTER TABLE ... DISABLE KEYS are not in the set table->keys_in_use_for_query. I.E., if a key is in this set, the optimizer assumes it is free to use it. The bug is that keys disabled with ALTER TABLE ... DISABLE KEYS still appear in table->keys_in_use_for_query When the TABLE object has been initialized with setup_tables(). Before setup_tables is called, however, keys that are disabled in the aforementioned way are not included in TABLE::keys_in_use_for_query. The provided patch changes the code that updates keys_is_use_for_query so that it assumes that keys_is_use_for_query already takes into account all disabled keys, and generally all keys that should be used by the query.
-
- 25 Jan, 2007 1 commit
-
-
sergefp@mysql.com authored
-
- 24 Jan, 2007 18 commits
-
-
sergefp@pylon.mylan authored
into mysql.com:/home/psergey/mysql-5.1-bug8804-r12-merge
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug8804-r12
-
sergefp@mysql.com authored
Fixed typo problem that surfaced after the merge
-
sergefp@pylon.mylan authored
into mysql.com:/home/psergey/mysql-5.1-bug8804-r12-merge
-
sergefp@mysql.com authored
identical pushed_cond_guards arrays. Allocate only one always.
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-bug8804-r12
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/merge-5.1-opt
-
gkodinov/kgeorge@macbook.gmz authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
geometry dependent parts moved to proper .test files
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.0/ndb-work
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.1/ndb-work
-
stewart@willster.(none) authored
-
tomas@poseidon.mysql.com authored
into poseidon.mysql.com:/home/tomas/mysql-5.0-ndb
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
- 23 Jan, 2007 20 commits
-
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
gkodinov/kgeorge@rakia.gmz authored
into rakia.gmz:/home/kgeorge/mysql/autopush/B6172-5.1-opt
-
gkodinov/kgeorge@macbook.gmz authored
RAND() must accept scalar expressions regardless of their kind. That includes both constant expressions and expressions that depend on column values. When the expression is constant the random seed can be initialized at compile time. However when the expression is not constant the random seed must be initialized at each invocation (while it still can be allocated at compile time). Implemented the above rules by extending Item_func_rand::val_real() to initialize the random seed at the correct place.
-
pekka@clam.ndb.mysql.com/clam.(none) authored
into clam.ndb.mysql.com:/export/space/pekka/ndb/version/my50-ndb
-
pekka@clam.(none) authored
into clam.ndb.mysql.com:/export/space/pekka/ndb/version/my51-ndb
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.0/bug25487
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.1/bug25567
-
stewart@willster.(none) authored
into willster.(none):/home/stewart/Documents/MySQL/5.1/bug25567
-
stewart@willster.(none) authored
-
pekka@clam.(none) authored
into clam.ndb.mysql.com:/export/space/pekka/ndb/version/my51-ndb
-
pekka@clam.ndb.mysql.com/clam.(none) authored
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/merge-5.1-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
stewart@willster.(none) authored
-
stewart@willster.(none) authored
aim is to: a) if set_connect_timeout called, timeout connect attempt (for retry on next call) after timeout period b) preserve existing blocking behaviour otherwise (for, e.g. mgmapi) Related to customer issue with long time deleting ndb_cluster_connection object. believe we're hanging on the connect(2) call until timeout (when we then realise we should exit the thread).
-
tomas@poseidon.mysql.com authored
into poseidon.mysql.com:/home/tomas/mysql-5.1-new-ndb
-
tomas@poseidon.mysql.com authored
Fix bug in event handling wrt early node shutdown
-
tomas@poseidon.mysql.com authored
-
tomas@poseidon.mysql.com authored
into poseidon.mysql.com:/home/tomas/mysql-5.1-new-ndb
-