- 22 Nov, 2006 4 commits
-
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21635
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21635
-
kroki/tomash@moonlight.intranet authored
expression cols. The problem was that MYSQL_FIELD::org_name was set for MIN() and MAX() functions (COUNT() is also mentioned in the bug report but was already fixed). After this patch for expressions MYSQL_FIELD::name is set to either expression itself or its alias, and other data origin fields of MYSQL_FILED (db, org_table, table, org_name) are empty strings.
-
- 21 Nov, 2006 4 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23159
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23159
-
kroki/tomash@moonlight.intranet authored
Make Prepared_stmt_count a global status variable, accessible via SHOW STATUS LIKE 'Prepared_stmt_count';. Documentation should be updated.
-
- 17 Nov, 2006 6 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23383
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23383
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug23383
-
kroki/tomash@moonlight.intranet authored
mysql_stmt_affected_rows() The problem was that affected_rows for prepared statement wasn't updated in the client library on the error. The solution is to always update affected_rows, which will be equal to -1 on the error.
-
bell@desktop.sanja.is.com.ua authored
-
- 16 Nov, 2006 4 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17047
-
kroki/tomash@moonlight.intranet authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug17047
-
kroki/tomash@moonlight.intranet authored
The problem was that some functions (namely IN() starting with 4.1, and CHAR() starting with 5.0) were returning NULL in certain conditions, while they didn't set their maybe_null flag. Because of that there could be some problems with 'IS NULL' check, and statements that depend on the function value domain, like CREATE TABLE t1 SELECT 1 IN (2, NULL);. The fix is to set maybe_null correctly.
-
- 13 Nov, 2006 3 commits
-
-
malff/marcsql@weblab.(none) authored
This change set implements the DROP TRIGGER IF EXISTS functionality. This fix is considered a bug and not a feature, because without it, there is no known method to write a database creation script that can create a trigger without failing, when executed on a database that may or may not contain already a trigger of the same name. Implementing this functionality closes an orthogonality gap between triggers and stored procedures / stored functions (which do support the DROP IF EXISTS syntax). In sql_trigger.cc, in mysql_create_or_drop_trigger, the code has been reordered to: - perform the tests that do not depend on the file system (access()), - get the locks (wait_if_global_read_lock, LOCK_open) - call access() - perform the operation - write to the binlog - unlock (LOCK_open, start_waiting_global_read_lock) This is to ensure that all the code that depends on the presence of the trigger file is executed in the same critical section, and prevents race conditions similar to the case fixed by Bug 14262 : - thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure - thread 2 executes CREATE TRIGGER - thread 2 logs CREATE TRIGGER - thread 1 logs DROP TRIGGER IF EXISTS The patch itself is based on code contributed by the MySQL community, under the terms of the Contributor License Agreement (See Bug 18161).
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg23651
-
dlenev@mockturtle.local authored
stored function invoked from different connections". Invocation of trigger which was using stored function from different connections caused server crashes (for non-debug server this happened in highly concurrent environment, but debug server failed on assertion in relatively simple scenario). Item_func_sp was not safe to use in triggers (in other words for re-execution from different threads) as artificial TABLE object pointed by Item_func_sp::dummy_table referenced incorrect THD object. To fix the problem we force re-initialization of this object for each re-execution of statement.
-
- 12 Nov, 2006 1 commit
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
- 11 Nov, 2006 3 commits
-
-
into mysql.com:/Users/kent/mysql/bk/mysql-5.0
-
Test for base directory when a RPM install corrected
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime
-
- 10 Nov, 2006 15 commits
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
tsmith@quadxeon.mysql.com authored
into quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/50
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M41/push-4.1
-
joerg@trift2. authored
into trift2.:/MySQL/M41/push-4.1
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mtr-4.1
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mtr-5.0
-
df@kahlann.erinye.com authored
into kahlann.erinye.com:/home/df/mysql/build/mtr-5.0
-
df@kahlann.erinye.com authored
-
petr/cps@outpost.site authored
into outpost.site:/home/cps/mysql/trees/4.1-runtime-bug9191
-
ted@ted.mysql.internal authored
-
into mysql.com:/Users/kent/mysql/bk/mysql-5.0
-
into mysql.com:/Users/kent/mysql/bk/lic/my50-lic
-
Added --force-restart pseudo server argument to shell version as well
-