Really? less then a week after we upgraded? Tough luck, haha :) Walter
OlinData: Professional services for MySQL Support * Consulting * Administration http://www.olindata.com On Tue, Feb 17, 2009 at 9:21 AM, Joerg Bruehe <joerg.bru...@sun.com> wrote: > Dear MySQL users, > > my sincere apologies for the noise - > this text is the final, official announcement; the word "DRAFT" in a > previous mailing's subject line was an oversight of mine. > > Jörg Brühe > > ===== > > Dear MySQL users, > > MySQL Community Server 5.0.77, a new version of the popular Open Source > Database Management System, has been released. The release is now > available in source and binary form for a number of platforms from our > download pages at > > http://dev.mysql.com/downloads/ > > and mirror sites. Note that not all mirror sites may be up to date at > this point in time, so if you can't find this version on some mirror, > please try again later or choose another download site. > > We welcome and appreciate your feedback, bug reports, bug fixes, > patches etc.: > > http://forge.mysql.com/wiki/Contributing > > The following section lists important, incompatible and security > changes since the previous (binary) MySQL Community Server 5.0.67 > release. The full changelog including many more fixes can be viewed > online at > > http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-77.html > > > This is a bugfix release for the current production release > family. It replaces MySQL 5.0.67 (binary) and 5.0.75 (source-only). > > Functionality added or changed: > > * Security Enhancement: To enable stricter control over the > location from which user-defined functions can be loaded, > the plugin_dir system variable has been backported from > MySQL 5.1. If the value is non-empty, user-defined > function object files can be loaded only from the > directory named by this variable. If the value is empty, > the behavior that is used prior to the inclusion of > plugin_dir applies: The UDF object files must be located > in a directory that is searched by your system's dynamic > linker. (Bug#37428: http://bugs.mysql.com/37428) > > * A new status variable, Queries, indicates the number of > statements executed by the server. This includes > statements executed within stored programs, unlike the > Questions variable which includes only statements sent to > the server by clients. > (Bug#41131: http://bugs.mysql.com/41131) > > * Previously, index hints did not work for FULLTEXT > searches. Now they work as follows: > For natural language mode searches, index hints are > silently ignored. For example, IGNORE INDEX(i) is ignored > with no warning and the index is still used. > For boolean mode searches, index hints are honored. > (Bug#38842: http://bugs.mysql.com/38842) > > Bugs fixed: > > * Important Change: Security Fix: Additional corrections > were made for the symlink-related privilege problem > originally addressed in MySQL 5.0.60. The original fix > did not correctly handle the data directory path name if > it contained symlinked directories in its path, and the > check was made only at table-creation time, not at > table-opening time later. > (Bug#32167: http://bugs.mysql.com/32167, CVE-2008-2079 > (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2 > 079)) > See also Bug#39277: http://bugs.mysql.com/39277. > > * Security Enhancement: The server consumed excess memory > while parsing statements with hundreds or thousands of > nested boolean conditions (such as OR (OR ... (OR ... > ))). This could lead to a server crash or incorrect > statement execution, or cause other client statements to > fail due to lack of memory. The latter result constitutes > a denial of service. > (Bug#38296: http://bugs.mysql.com/38296) > > * Incompatible Change: There were some problems using > DllMain() hook functions on Windows that automatically do > global and per-thread initialization for libmysqld.dll: > > + Per-thread initialization: MySQL internally counts > the number of active threads, which causes a delay > in my_end() if not all threads have exited. But > there are threads that can be started either by > Windows internally (often in TCP/IP scenarios) or by > users. Those threads do not necessarily use > libmysql.dll functionality but still contribute to > the open-thread count. (One symptom is a five-second > delay in times for PHP scripts to finish.) > > + Process-initialization: my_init() calls WSAStartup > that itself loads DLLs and can lead to a deadlock in > the Windows loader. > > To correct these problems, DLL initialization code now is > not invoked from libmysql.dll by default. To obtain the > previous behavior (DLL initialization code will be > called), set the LIBMYSQL_DLLINIT environment variable to > any value. This variable exists only to prevent breakage > of existing Windows-only applications that do not call > mysql_thread_init() and work okay today. Use of > LIBMYSQL_DLLINIT is discouraged and is removed in MySQL > 6.0. (Bug#37226: http://bugs.mysql.com/37226, > Bug#33031: http://bugs.mysql.com/33031) > > * Incompatible Change: SHOW STATUS took a lot of CPU time > for calculating the value of the > Innodb_buffer_pool_pages_latched status variable. Now > this variable is calculated and included in the output of > SHOW STATUS only if the UNIV_DEBUG symbol is defined at > MySQL build time. > (Bug#36600: http://bugs.mysql.com/36600) > > * Incompatible Change: In connection with view creation, > the server created arc directories inside database > directories and maintained useless copies of .frm files > there. Creation and renaming procedures of those copies > as well as creation of arc directories has been > discontinued. > This change does cause a problem when downgrading to > older server versions which manifests itself under these > circumstances: > > 1. Create a view v_orig in MySQL 5.0.72 or higher. > > 2. Rename the view to v_new and then back to v_orig. > > 3. Downgrade to an older 5.0.x server and run > mysql_upgrade. > > 4. Try to rename v_orig to v_new again. This operation > fails. > > As a workaround to avoid this problem, use either of > these approaches: > > + Dump your data using mysqldump before downgrading > and reload the dump file after downgrading. > > + Instead of renaming a view after the downgrade, drop > it and recreate it. > > The downgrade problem introduced by the fix for this bug > has been addressed as > Bug#40021: http://bugs.mysql.com/40021. > (Bug#17823: http://bugs.mysql.com/17823) > > * Replication: When rotating relay log files, the slave > deletes relay log files and then edits the relay log > index file. Formerly, if the slave shut down unexpectedly > between these two events, the relay log index file could > then reference relay logs that no longer existed. > Depending on the circumstances, this could when > restarting the slave cause either a race condition or the > failure of replication. > (Bug#38826: http://bugs.mysql.com/38826, > Bug#39325: http://bugs.mysql.com/39325) > > * In example option files provided in MySQL distributions, > the thread_stack value was increased from 64K to 128K. > (Bug#41577: http://bugs.mysql.com/41577) > > * SET PASSWORD caused a server crash if the account name > was given as CURRENT_USER(). > (Bug#41456: http://bugs.mysql.com/41456) > > * The INFORMATION_SCHEMA.SCHEMA_PRIVILEGES table was > limited to 7680 rows. > (Bug#41079: http://bugs.mysql.com/41079) > > * In debug builds, obsolete debug code could be used to > crash the server. > (Bug#41041: http://bugs.mysql.com/41041) > > * CHECK TABLE ... FOR UPGRADE did not check for > incompatible collation changes made in MySQL 5.0.48 > (Bug#27562: http://bugs.mysql.com/27562, > Bug#29461: http://bugs.mysql.com/29461, > Bug#29499: http://bugs.mysql.com/29499). This also > affects mysqlcheck and mysql_upgrade, which cause that > statement to be executed. See Section 2.18.3, "Checking > Whether Table Indexes Must Be Rebuilt." > (Bug#40984: http://bugs.mysql.com/40984) > See also Bug#39585: http://bugs.mysql.com/39585. > > * Some queries that used a "range checked for each record" > scan could return incorrect results. > (Bug#40974: http://bugs.mysql.com/40974) > > * Certain SELECT queries could fail with a Duplicate entry > error. (Bug#40953: http://bugs.mysql.com/40953) > > * The FEDERATED handler had a memory leak. > (Bug#40875: http://bugs.mysql.com/40875) > > * IF(..., CAST(longtext_val AS UNSIGNED), signed_val) as an > argument to an aggregate function could cause an > assertion failure. > (Bug#40761: http://bugs.mysql.com/40761) > > * Prepared statements allowed invalid dates to be inserted > when the ALLOW_INVALID_DATES SQL mode was not enabled. > (Bug#40365: http://bugs.mysql.com/40365) > > * mc.exe is no longer needed to compile MySQL on Windows. > This makes it possible to build MySQL from source using > Visual Studio Express 2008. > (Bug#40280: http://bugs.mysql.com/40280) > > * Support for the revision field in .frm files has been > removed. This addresses the downgrading problem > introduced by the fix for > Bug#17823: http://bugs.mysql.com/17823. > (Bug#40021: http://bugs.mysql.com/40021) > > * If the operating system is configured to return leap > seconds from OS time calls or if the MySQL server uses a > time zone definition that has leap seconds, functions > such as NOW() could return a value having a time part > that ends with :59:60 or :59:61. If such values are > inserted into a table, they would be dumped as is by > mysqldump but considered invalid when reloaded, leading > to backup/restore problems. > Now leap second values are returned with a time part that > ends with :59:59. This means that a function such as > NOW() can return the same value for two or three > consecutive seconds during the leap second. It remains > true that literal temporal values having a time part that > ends with :59:60 or :59:61 are considered invalid. > For additional details about leap-second handling, see > Section 9.7.2, "Time Zone Leap Second Support." > (Bug#39920: http://bugs.mysql.com/39920) > > * The server could crash during a sort-order optimization > of a dependent subquery. > (Bug#39844: http://bugs.mysql.com/39844) > > * With the ONLY_FULL_GROUP_BY SQL mode enabled, the check > for non-aggregated columns in queries with aggregate > functions, but without a GROUP BY clause was treating all > the parts of the query as if they were in the select > list. This is fixed by ignoring the non-aggregated > columns in the WHERE clause. > (Bug#39656: http://bugs.mysql.com/39656) > > * The server crashed if an integer field in a CSV file did > not have delimiting quotes. > (Bug#39616: http://bugs.mysql.com/39616) > > * CHECK TABLE failed for MyISAM INFORMATION_SCHEMA tables. > (Bug#39541: http://bugs.mysql.com/39541) > > * For a TIMESTAMP column in an InnoDB table, testing the > column with multiple conditions in the WHERE clause > caused a server crash. > (Bug#39353: http://bugs.mysql.com/39353) > > * The server returned a column type of VARBINARY rather > than DATE as the result from the COALESCE(), IFNULL(), > IF(), GREATEST(), or LEAST() functions or CASE expression > if the result was obtained using filesort in an anonymous > temporary table during the query execution. > (Bug#39283: http://bugs.mysql.com/39283) > > * References to local variables in stored procedures are > replaced with NAME_CONST(name, value) when written to the > binary log. However, an "illegal mix of collation" error > might occur when executing the log contents if the > value's collation differed from that of the variable. Now > information about the variable collation is written as > well. (Bug#39182: http://bugs.mysql.com/39182) > > * Some recent releases for Solaris 10 were built on Solaris > 10 U5, which included a new version of libnsl.so that > does not work on U4 or earlier. To correct this, Solaris > 10 builds now are created on machines that do not have > that upgraded libnsl.so, so that they will work on > Solaris 10 installations both with and without the > upgraded libnsl.so. > (Bug#39074: http://bugs.mysql.com/39074) > > * With binary logging enabled CREATE VIEW was subject to > possible buffer overwrite and a server crash. > (Bug#39040: http://bugs.mysql.com/39040) > > * Queries of the form SELECT ... REGEXP BINARY NULL could > lead to a hung or crashed server. > (Bug#39021: http://bugs.mysql.com/39021) > > * Statements of the form INSERT ... SELECT .. ON DUPLICATE > KEY UPDATE col_name = DEFAULT could result in a server > crash. (Bug#39002: http://bugs.mysql.com/39002) > > * Column names constructed due to wild-card expansion done > inside a stored procedure could point to freed memory if > the expansion was performed after the first call to the > stored procedure. > (Bug#38823: http://bugs.mysql.com/38823) > > * Repeated CREATE TABLE ... SELECT statements, where the > created table contained an AUTO_INCREMENT column, could > lead to an assertion failure. > (Bug#38821: http://bugs.mysql.com/38821) > > * If delayed insert failed to upgrade the lock, it did not > free the temporary memory storage used to keep newly > constructed BLOB values in memory, resulting in a memory > leak. (Bug#38693: http://bugs.mysql.com/38693) > > * A server crash resulted from concurrent execution of a > multiple-table UPDATE that used a NATURAL or USING join > together with FLUSH TABLES WITH READ LOCK or ALTER TABLE > for the table being updated. > (Bug#38691: http://bugs.mysql.com/38691) > > * On ActiveState Perl, mysql-test-run.pl --start-and-exit > started but did not exit. > (Bug#38629: http://bugs.mysql.com/38629) > > * Server-side cursors were not initialized properly, which > could cause a server crash. > (Bug#38486: http://bugs.mysql.com/38486) > > * Stored procedures involving substrings could crash the > server on certain platforms due to invalid memory reads. > (Bug#38469: http://bugs.mysql.com/38469) > > * A server crash or Valgrind warnings could result when a > stored procedure selected from a view that referenced a > function. (Bug#38291: http://bugs.mysql.com/38291) > > * Incorrect handling of aggregate functions when loose > index scan was used caused a server crash. > (Bug#38195: http://bugs.mysql.com/38195) > > * Queries containing a subquery with DISTINCT and ORDER BY > could cause a server crash. > (Bug#38191: http://bugs.mysql.com/38191) > > * Queries with a HAVING clause could return a spurious row. > (Bug#38072: http://bugs.mysql.com/38072) > > * Use of spatial data types in prepared statements could > cause memory leaks or server crashes. > (Bug#37956: http://bugs.mysql.com/37956, > Bug#37671: http://bugs.mysql.com/37671) > > * The server crashed if an argument to a stored procedure > was a subquery that returned more than one row. > (Bug#37949: http://bugs.mysql.com/37949) > > * When analyzing the possible index use cases, the server > was incorrectly reusing an internal structure, leading to > a server crash. (Bug#37943: http://bugs.mysql.com/37943) > > * A SELECT with a NULL NOT IN condition containing a > complex subquery from the same table as in the outer > select caused an assertion failure. > (Bug#37894: http://bugs.mysql.com/37894) > > * For InnoDB tables, ORDER BY ... DESC sometimes returned > results in ascending order. > (Bug#37830: http://bugs.mysql.com/37830) > > * If a table has a BIT NOT NULL column c1 with a length > shorter than 8 bits and some additional NOT NULL columns > c2, ..., and a SELECT query has a WHERE clause of the > form (c1 = constant) AND c2 ..., the query could return > an unexpected result set. > (Bug#37799: http://bugs.mysql.com/37799) > > * Nesting of IF() inside of SUM() could cause an extreme > server slowdown. (Bug#37662: http://bugs.mysql.com/37662) > > * The MONTHNAME() and DAYNAME() functions returned a binary > string, so that using LOWER() or UPPER() had no effect. > Now MONTHNAME() and DAYNAME() return a value in > character_set_connection character set. > (Bug#37575: http://bugs.mysql.com/37575) > > * TIMEDIFF() was erroneously treated as always returning a > positive result. Also, CAST() of TIME values to DECIMAL > dropped the sign of negative values. > (Bug#37553: http://bugs.mysql.com/37553) > > * mysqlcheck used SHOW FULL TABLES to get the list of > tables in a database. For some problems, such as an empty > .frm file for a table, this would fail and mysqlcheck > then would neglect to check other tables in the database. > (Bug#37527: http://bugs.mysql.com/37527) > > * The <=> operator could return incorrect results when > comparing NULL to DATE, TIME, or DATETIME values. > (Bug#37526: http://bugs.mysql.com/37526) > > * Updating a view with a subquery in the CHECK option could > cause an assertion failure. > (Bug#37460: http://bugs.mysql.com/37460) > > * Statements that displayed the value of system variables > (for example, SHOW VARIABLES) expect variable values to > be encoded in character_set_system. However, variables > set from the command line such as basedir or datadir were > encoded using character_set_filesystem and not converted > correctly. (Bug#37339: http://bugs.mysql.com/37339) > > * For a MyISAM table with CHECKSUM = 1 and ROW_FORMAT = > DYNAMIC table options, a data consistency check (maximum > record length) could fail and cause the table to be > marked as corrupted. > (Bug#37310: http://bugs.mysql.com/37310) > > * The max_length result set metadata value was calculated > incorrectly under some circumstances. > (Bug#37301: http://bugs.mysql.com/37301) > > * CREATE INDEX could crash with InnoDB plugin 1.0.1. > (Bug#37284: http://bugs.mysql.com/37284) > > * Certain boolean-mode FULLTEXT searches that used the > truncation operator did not return matching records and > calculated relevance incorrectly. > (Bug#37245: http://bugs.mysql.com/37245) > > * The NO_BACKSLASH_ESCAPES SQL mode was ignored for LOAD > DATA INFILE and SELECT INTO ... OUTFILE. The setting is > taken into account now. > (Bug#37114: http://bugs.mysql.com/37114) > > * On a 32-bit server built without big tables support, the > offset argument in a LIMIT clause might be truncated due > to a 64-bit to 32-bit cast. > (Bug#37075: http://bugs.mysql.com/37075) > > * If the server failed to expire binary log files at > startup, it could crash. > (Bug#37027: http://bugs.mysql.com/37027) > > * The code for the ut_usectime() function in InnoDB did not > handle errors from the gettimeofday() system call. Now it > retries gettimeofday() several times and updates the > value of the Innodb_row_lock_time_max status variable > only if ut_usectime() was successful. > (Bug#36819: http://bugs.mysql.com/36819) > > * Use of CONVERT() with GROUP BY to convert numeric values > to CHAR could return truncated results. > (Bug#36772: http://bugs.mysql.com/36772) > > * A query which had an ORDER BY DESC clause that is > satisfied with a reverse range scan could cause a server > crash for some specific CPU/compiler combinations. > (Bug#36639: http://bugs.mysql.com/36639) > > * Dumping information about locks in use by sending a > SIGHUP signal to the server or by invoking the mysqladmin > debug command could lead to a server crash in debug > builds or to undefined behavior in production builds. > (Bug#36579: http://bugs.mysql.com/36579) > > * The mysql client, when built with Visual Studio 2005, did > not display Japanese characters. > (Bug#36279: http://bugs.mysql.com/36279) > > * When the fractional part in a multiplication of DECIMAL > values overflowed, the server truncated the first operand > rather than the longest. Now the server truncates so as > to produce more precise multiplications. > (Bug#36270: http://bugs.mysql.com/36270) > > * A read past the end of the string could occur while > parsing the value of the --innodb-data-file-path option. > (Bug#36149: http://bugs.mysql.com/36149) > > * Host name values in SQL statements were not being checked > for '@', which is illegal according to RFC952. > (Bug#35924: http://bugs.mysql.com/35924) > > * The UUID() function returned UUIDs with the wrong time; > this was because the offset for the time part in UUIDs > was miscalculated. > (Bug#35848: http://bugs.mysql.com/35848) > > * SHOW CREATE TABLE did not display a printable value for > the default value of BIT columns. > (Bug#35796: http://bugs.mysql.com/35796) > > * mysql_install_db failed on machines that had the host > name set to localhost. > (Bug#35754: http://bugs.mysql.com/35754) > > * Dynamic plugins failed to load on i5/OS. > (Bug#35743: http://bugs.mysql.com/35743) > > * Freeing of an internal parser stack during parsing of > complex stored programs caused a server crash. > (Bug#35577: http://bugs.mysql.com/35577, > Bug#37269: http://bugs.mysql.com/37269, > Bug#37228: http://bugs.mysql.com/37228) > > * The max_length metadata value was calculated incorrectly > for the FORMAT() function, which could cause incorrect > result set metadata to be sent to clients. > (Bug#35558: http://bugs.mysql.com/35558) > > * Index scans performed with the sort_union() access method > returned wrong results, caused memory to be leaked, and > caused temporary files to be deleted when the limit set > by sort_buffer_size was reached. > (Bug#35477: http://bugs.mysql.com/35477, > Bug#35478: http://bugs.mysql.com/35478) > > * If the server crashed with an InnoDB error due to > unavailability of undo slots, errors could persist during > rollback when the server was restarted: There are two > UNDO slot caches (for INSERT and UPDATE). If all slots > end up in one of the slot caches, a request for a slot > from the other slot cache would fail. This can happen if > the request is for an UPDATE slot and all slots are in > the INSERT slot cache, or vice versa. > (Bug#35352: http://bugs.mysql.com/35352) > > * For InnoDB tables, ALTER TABLE DROP failed if the name of > the column to be dropped began with "foreign". > (Bug#35220: http://bugs.mysql.com/35220) > > * perror on Windows did not know about Win32 system error > codes. (Bug#34825: http://bugs.mysql.com/34825) > > * EXPLAIN EXTENDED evaluation of aggregate functions that > required a temporary table caused a server crash. > (Bug#34773: http://bugs.mysql.com/34773) > > * Queries of the form SELECT ... WHERE string = ANY(...) > failed when the server used a single-byte character set > and the client used a multi-byte character set. > (Bug#34760: http://bugs.mysql.com/34760) > See also Bug#20835: http://bugs.mysql.com/20835. > > * Using OPTIMIZE TABLE as the first statement on an InnoDB > table with an AUTO_INCREMENT column could cause a server > crash. (Bug#34286: http://bugs.mysql.com/34286) > > * mysql_install_db failed if the server was running with an > SQL mode of TRADITIONAL. This program now resets the SQL > mode internally to avoid this problem. > (Bug#34159: http://bugs.mysql.com/34159) > > * The mysql client incorrectly parsed statements containing > the word "delimiter" in mid-statement. > This fix is different from the one applied for this bug > in MySQL 5.0.66. (Bug#33812: http://bugs.mysql.com/33812) > See also Bug#38158: http://bugs.mysql.com/38158. > > * For a stored procedure containing a SELECT * ... RIGHT > JOIN query, execution failed for the second call. > (Bug#33811: http://bugs.mysql.com/33811) > > * Previously, use of index hints with views (which do not > have indexes) produced the error ERROR 1221 (HY000): > Incorrect usage of USE/IGNORE INDEX and VIEW. Now this > produces ERROR 1176 (HY000): Key '...' doesn't exist in > table '...', the same error as for base tables without an > appropriate index. > (Bug#33461: http://bugs.mysql.com/33461) > > * Cached queries that used 256 or more tables were not > properly cached, so that later query invalidation due to > a TRUNCATE TABLE for one of the tables caused the server > to hang. (Bug#33362: http://bugs.mysql.com/33362) > > * Some division operations produced a result with incorrect > precision. (Bug#31616: http://bugs.mysql.com/31616) > > * mysql_upgrade attempted to use the /proc file system even > on systems that do not have it. > (Bug#31605: http://bugs.mysql.com/31605) > > * mysqldump could fail to dump views containing a large > number of columns. > (Bug#31434: http://bugs.mysql.com/31434) > > * Queries executed using join buffering of BIT columns > could produce incorrect results. > (Bug#31399: http://bugs.mysql.com/31399) > > * ALTER TABLE CONVERT TO CHARACTER SET did not convert > TINYTEXT or MEDIUMTEXT columns to a longer text type if > necessary when converting the column to a different > character set. (Bug#31291: http://bugs.mysql.com/31291) > > * On NetWare, mysql_install_db could appear to execute > normally even if it failed to create the initial > databases. (Bug#30129: http://bugs.mysql.com/30129) > > * The Serbian translation for the > ER_INCORRECT_GLOBAL_LOCAL_VAR error was corrected. > (Bug#29738: http://bugs.mysql.com/29738) > > * XA transaction rollbacks could result in corrupted > transaction states and a server crash. > (Bug#28323: http://bugs.mysql.com/28323) > > * On Windows, Visual Studio does not take into account some > x86 hardware limitations, which led to incorrect results > converting large DOUBLE values to unsigned BIGINT values. > (Bug#27483: http://bugs.mysql.com/27483) > > * SSL support was not included in some "generic" RPM > packages. (Bug#26760: http://bugs.mysql.com/26760) > > * In some cases, the parser interpreted the ; character as > the end of input and misinterpreted stored program > definitions. (Bug#26030: http://bugs.mysql.com/26030) > > * The Questions status variable is intended as a count of > statements sent by clients to the server, but was also > counting statements executed within stored routines. > (Bug#24289: http://bugs.mysql.com/24289) > > * For access to the INFORMATION_SCHEMA.VIEWS table, the > server did not check the SHOW VIEW and SELECT privileges, > leading to inconsistency between output from that table > and the SHOW CREATE VIEW statement. > (Bug#22763: http://bugs.mysql.com/22763) > > * The FLUSH PRIVILEGES statement did not produce an error > when it failed. (Bug#21226: http://bugs.mysql.com/21226) > > * A race condition between the mysqld.exe server and the > Windows service manager could lead to inability to stop > the server from the service manager. > (Bug#20430: http://bugs.mysql.com/20430) > > * mysqld_safe would sometimes fail to remove the pid file > for the old mysql process after a crash. As a result, the > server would fail to start due to a false A mysqld > process already exists... error. > (Bug#11122: http://bugs.mysql.com/11122) > > > On behalf of the MySQL Build Team at Sun, > Jörg Brühe > > -- > Joerg Bruehe, MySQL Build Team, joerg.bru...@sun.com > Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer > Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 > > > > > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=li...@olindata.com > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
