MySQL Server 5.4.3-beta has been released
Dear MySQL users, MySQL Server 5.4.3-beta, a new version of the popular Open Source Database Management System, has been released. Bear in mind that this is a beta release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.1, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ MySQL 5.4 is based on MySQL 5.1 but includes several high-impact changes to address scalability and performance issues in MySQL Server. These changes exploit advances in hardware and CPU design and enable better utilization of existing hardware. MySQL 5.4 currently has Beta status. For an overview of what's new in MySQL 5.4, please see http://dev.mysql.com/doc/refman/5.4/en/news-5-4-x.html For information on installing MySQL 5.4.3 on new servers, please see the MySQL installation documentation at http://dev.mysql.com/doc/refman/5.4/en/installing.html For upgrading from previous MySQL releases, please see the important upgrade considerations at http://dev.mysql.com/doc/mysql-5.4-features/en/index.html Some other pointers you might like to follow are http://dev.mysql.com/doc/refman/5.4/en/mysql-nutshell.html http://dev.mysql.com/doc/refman/5.4/en/configuration-changes-5-4.html http://dev.mysql.com/doc/refman/5.4/en/upgrading-from-previous-series.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ 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 the changes in the MySQL source code since the previous released version of MySQL 5.4. It may also be viewed online at http://dev.mysql.com/doc/refman/5.4/en/news-5-4-3.html Enjoy! Timothy Smith The MySQL build team at Sun Microsystems == Functionality added or changed: * Incompatible Change: If you upgrade to MySQL 5.4.3 from an earlier 5.4 release, the server may fail to start due to changes in the default values of innodb_log_files_in_group and innodb_log_file_size, which differ from those in earlier 5.4 releases. You should discard the old InnoDB log files and let MySQL 5.4.3 create new ones. It is necessary to shut down your current server cleanly so that no outstanding transaction information remains in the log. The procedure to use depends on the value of innodb_fast_shutdown used in your current server: + If innodb_fast_shutdown is not set to 2: Stop your current MySQL server and make sure that it shuts down without errors (to ensure that there is no information for outstanding transactions in the log). Copy the old log files into a safe place in case something went wrong during the shutdown and you need them to recover the tablespace. Delete the old log files and edit my.cnf if necessary to specify the desired log file configuration. Then upgrade to MySQL 5.4.3 and start the new server. mysqld sees that no InnoDB log files exist at startup and creates new ones. + If innodb_fast_shutdown is set to 2: Shut down your current server, set innodb_fast_shutdown to 1, and restart the server. The server should be allowed to recover. Then you should shut down the server again and follow the procedure described in the preceding item to change InnoDB log file size. Set innodb_fast_shutdown back to 2 and start the MySQL 5.4.3 server. * Incompatible Change: The following list indicates InnoDB configuration changes in MySQL 5.4.3, compared to previous versions of MySQL 5.4. For a description of cumulative changes in MySQL 5.4 compared to MySQL 5.1, see Section 1.4.1, "What Is New in MySQL 5.4." The default value of these system variables was changed: Variable Change in default value innodb_autoextend_increment From 64MB to 8MB innodb_buffer_pool_size From 1GB to 128MB innodb_log_buffer_size From 16MB to 8MB innodb_log_file_sizeFrom 128MB to 5MB innodb_log_files_in_group From 3 to 2 innodb_read_io_threads From 8 to 4 innodb_write_io_threads From 8 to 4 These default value changes in most cases revert changes made in earlier MySQL 5.4 releases. The result is that the defaults are more similar to those in MySQL 5.1. * On Linux (and perhaps other systems), the performance of MySQL Server can be improved by using a different malloc() implementation, developed by Google and called tcmalloc. The gain is noticeable with a higher number of simultaneous users. MySQL 5.4.1 was linked against
MySQL Server 5.1.37 has been released
ion for geometry data collections did not rigorously check for available data, leading to invalid reads and server crashes. (Bug#44684: http://bugs.mysql.com/44684) * If an error occurred during the creation of a table (for example, the table already existed) having an AUTO_INCREMENT column and a BEFORE trigger that used the INSERT ... SELECT construct, an internal flag was not reset properly. This led to a crash the next time that the table was opened again. (Bug#44653: http://bugs.mysql.com/44653) * For queries with a sufficient number of subqueries in the FROM clause of this form: SELECT * FROM (SELECT 1) AS t1, (SELECT 2) AS t2, (SELECT 3) AS t3, ... The query failed with a Too high level of nesting for select error, as though the query had this form: SELECT * FROM (SELECT 1 FROM (SELECT 2 FROM (SELECT 3 FROM ... (Bug#44156: http://bugs.mysql.com/44156) * configure.in contained references to literal instances of nm and libc, rather than to variables parameterized for the proper values on the current platform. (Bug#42721: http://bugs.mysql.com/42721) * configure.in did not properly check for the pthread_setschedprio() function. (Bug#42599: http://bugs.mysql.com/42599) * A workaround for a Sun Studio bug was instituted. (Bug#41710: http://bugs.mysql.com/41710) * Valgrind warnings that occurred for SHOW TABLE STATUS with InnoDB tables were silenced. (Bug#38479: http://bugs.mysql.com/38479) * In the mysql client, if the server connection was lost during repeated status commands, the client would fail to detect this and command output would be inconsistent. (Bug#37274: http://bugs.mysql.com/37274) * When invoked to start multiple server instances, mysqld_multi sometimes would fail to start them all due to not changing location into the base directory for each instance. (Bug#36654: http://bugs.mysql.com/36654) * Renaming a column that appeared in a foreign key definition did not update the foreign key definition with the new column name. (Bug#21704: http://bugs.mysql.com/21704) -- Timothy Smith, Release Engineering, MySQL Database Technology Group, Sun Microsystems -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
MySQL Server 5.4.1-beta has been released
Dear MySQL users, MySQL Server 5.4.1-beta, a new version of the popular Open Source Database Management System, has been released. Bear in mind that this is a beta release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.1, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ MySQL 5.4 is based on MySQL 5.1 but includes small, high-impact changes to address scalability and performance issues in MySQL Server. These changes exploit advances in hardware and CPU design and enable better utilization of existing hardware. MySQL 5.4 currently has Beta status. For an overview of what's new in MySQL 5.4, please see http://dev.mysql.com/doc/refman/5.4/en/news-5-4-x.html This release does not differ from 5.4.0, except that binary packages are built on all MySQL-supported platforms, including Windows binaries that take advantage of the 5.4 scalability improvements. We expect that the scalability improvements will also benefit users of 64-bit Mac OSX and FreeBSD as well as 64-bit Linux/Solaris/SPARC, and potentially also users of 32-bit versions of these platforms, and will greatly appreciate Community feedback on them since we don't have the bandwidth to test them all. Please use the internals mailing list, at http://lists.mysql.com/internals/ For information on installing MySQL 5.4.1 on new servers, please see the MySQL 5.1 installation documentation http://dev.mysql.com/doc/refman/5.1/en/installing.html For upgrading from previous MySQL releases, please see the important upgrade considerations at http://dev.mysql.com/doc/mysql-5.4-features/en/index.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ 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 Enjoy! Timothy Smith The MySQL build team at Sun Microsystems -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
MySQL Community Server 5.1.35 has been released
Dear MySQL users, MySQL Community Server 5.1.35, a new version of the popular Open Source Database Management System, has been released. MySQL 5.1.35 is recommended for use on production systems. For an overview of what's new in MySQL 5.1, please see http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html For information on installing MySQL 5.1.35 on new servers or upgrading to MySQL 5.1.35 from previous MySQL releases, please see http://dev.mysql.com/doc/refman/5.1/en/installing.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ 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 For information on open issues in MySQL 5.1, please see the errata list at http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.1. It may also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-35.html Enjoy! Timothy Smith The MySQL build team at Sun Microsystems === This release of MySQL has two known outstanding issues for Windows: * The .msi installer does not detect an existing root password on the initial configuration attempt. To work around this, install and configure MySQL as normal, but skip any changes to security. (There is a checkbox that allows this on the security screen of the configuration wizard.) Then check your settings: + If the old root password and security settings are okay, you are done and can proceed to use MySQL. + Otherwise, reconfigure with the wizard and make any changes on the second configuration attempt. The wizard will properly prompt for the existing root password and allow changes to be made. This issue has been filed as Bug#45200: http://bugs.mysql.com/45200 for correction in a future release. * The Windows configuration wizard allows changes to InnoDB settings during a reconfiguration operation. For an upgrade, this may cause difficulties. To work around this, use one of the following alternatives: + Do not change InnoDB settings. + Copy files from the old InnoDB location to the new one. This issue has been filed as Bug#45201: http://bugs.mysql.com/45201 for correction in a future release. Bugs fixed: * Important Change: Replication: The transactional behavior of STOP SLAVE has changed. Formerly, it took effect immediately, even inside a transaction; now, it waits until the current replication event group (if any) has finished executing, or until the user issues a KILL QUERY or KILL CONNECTION statement. This was done in order to solve the problem encountered when replication was stopped while a nontransactional slave was replicating a transaction on the master. (It was impossible to roll back a mixed-engines transaction when one of the engines was nontransactional, which meant that the slave could not safely re-apply any transaction that had been interrupted by STOP SLAVE.) (Bug#319: http://bugs.mysql.com/319, Bug#38205: http://bugs.mysql.com/38205) See also Bug#43217: http://bugs.mysql.com/43217. * Partitioning: When a value was equal to a PARTITION ... VALUES LESS THAN (value) value other than MAXVALUE, the corresponding partition was not pruned. (Bug#42944: http://bugs.mysql.com/42944) * Replication: Unrelated errors occurring during the execution of RESET SLAVE could cause the slave to crash. (Bug#44179: http://bugs.mysql.com/44179) * Replication: The --slave-skip-errors option had no effect when using row-based logging format. (Bug#39393: http://bugs.mysql.com/39393) * Replication: The following erors were not correctly reported: + Failures during slave thread initialization + Failures while initializing the relay log position (immediately following the starting of the slave thread) + Failures while processing queries passed through the --init_slave option. Information about these types of failures can now be found in the output of SHOW SLAVE STATUS. (Bug#38197: http://bugs.mysql.com/38197) * Replication: Killing the thread executing a DDL statement, after it had finished its execution but before it had written the binlog event, caused the error code in the binlog event to be set (incorrectly) to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED, which caused replication to fail. (Bug#37145: http://bugs.mysql.com/37145)
MySQL Server 5.1.30 has been released
Dear MySQL users, We are proud to present to you the MySQL Server 5.1.30 GA release, the first 5.1 production version of the popular open source database. MySQL 5.1.30 is recommended for use on production systems. MySQL 5.1 provides a number of new enhancements including: - Table and index partitioning - Row-based and mixed replication - Built-in job scheduler - Improved XML handling with XPath support - New SQL diagnostic aids and performance utilities - The return of the embedded library (libmysqld) For a more complete look at what's new in MySQL 5.1, please see http://dev.mysql.com/doc/refman/5.1/en/mysql-nutshell.html For information on installing MySQL 5.1.30 on new servers or upgrading to MySQL 5.1.30 from previous MySQL releases, please see http://dev.mysql.com/doc/refman/5.1/en/installing.html MySQL Server is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ 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 For information on open issues in MySQL 5.1, please see the errata list at http://dev.mysql.com/doc/refman/5.1/en/open-bugs.html The following section lists the changes in the MySQL source code since the previous released version of MySQL 5.1. It may also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-30.html Sincerely, Kent Boortz The MySQL build team at Sun Microsystems === Bugs fixed: * Partitioning: A SELECT using a range WHERE condition with an ORDER BY on a partitioned table caused a server crash. (Bug#40494: http://bugs.mysql.com/40494) * Partitioning: Dropping or creating an index on a partitioned table managed by the InnoDB Plugin locked the table. (Bug#37453: http://bugs.mysql.com/37453) * Replication: Row-based replication failed with non-partitioned MyISAM tables having no indexes. (Bug#40004: http://bugs.mysql.com/40004) * With statement-based binary logging format and a transaction isolation level of READ COMMITTED or stricter, InnoDB printed an error because statement-based logging might lead to inconsistency between master and slave databases. However, this error was printed even when binary logging was not enabled (in which case, no such inconsistency can occur). (Bug#40360: http://bugs.mysql.com/40360) * The CHECK TABLE ... FOR UPGRADE statement did not check for incompatible collation changes made in MySQL 5.1.24. (This also affects mysqlcheck and mysql_upgrade, which cause that statement to be executed.) Prior to this fix, a binary upgrade (performed without dumping tables with mysqldump before the upgrade and reloading the dump file after the upgrade) would corrupt tables. After the fix, CHECK TABLE ... FOR UPGRADE properly detects the problem and upgrades tables. However, the fix is not backward compatible and can result in a downgrading problem under these circumstances: 1. Perform a binary upgrade to a version of MySQL that includes the fix. 2. Run CHECK TABLE ... FOR UPGRADE (or mysqlcheck or mysql_upgrade) to upgrade tables. 3. Perform a binary downgrade to a version of MySQL that does not include the fix. The solution is to dump tables with mysqldump before the downgrade and reload the dump file after the downgrade. Alternatively, drop and recreate affected indexes. (Bug#40053: http://bugs.mysql.com/40053) * 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) * XA transaction rollbacks could result in corrupted transaction states and a server crash. (Bug#28323: http://bugs.mysql.com/28323) * ALTER TABLE for an ENUM column could change column values. (Bug#23113: http://bugs.mysql.com/23113) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
MySQL 6.0.6 Alpha has been released
Dear MySQL users, MySQL 6.0.6-alpha, a new version of the MySQL database system has been released. The main page for MySQL 6.0 release is at http://www.mysql.com/mysql60/ MySQL 6.0 includes two new storage engines: the transactional Falcon engine, and the crash-safe Maria engine. If you are new to the Falcon storage engine and need more information, please read the Falcon Evaluation Guide at http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php and the Falcon White Paper at http://www.mysql.com/why-mysql/white-papers/storage-engines-falcon.php The Maria storage engine is a crash safe version of MyISAM. Maria supports all of the main functionality of the MyISAM engine, but includes recovery support (in the event of a system crash), full logging (including CREATE, DROP, RENAME and TRUNCATE operations), all MyISAM row formats and a new Maria specific row format. Maria is documented at http://dev.mysql.com/doc/refman/6.0/en/se-maria.html MySQL 6.0.6-alpha is available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/mysql/6.0.html 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 vers ion on some mirror, please try again later or choose another download site. We welcome and appreciate your feedback, bug reports, bug fixes, and patches at http://forge.mysql.com/wiki/Contributing The following section lists the changes in the MySQL source code since the previous version of MySQL 6.0. It can also be viewed at http://dev.mysql.com/doc/refman/6.0/en/news-6-0-6.html Sincerely, Timothy Smith The MySQL build team at Sun Microsystems === News from the Changelog: Functionality added or changed: * Important Change: Incompatible Change: The FEDERATED storage engine is now disabled by default in binary distributions. The engine is still available and can be enabled by starting the server with the --federated option. (Bug#37069: http://bugs.mysql.com/37069) * Incompatible Change: The engines column in the mysql.online_backup table has been renamed to drivers to better reflect its contents. (Bug#34965: http://bugs.mysql.com/34965) * Incompatible Change: A change has been made to the way that the server handles prepared statements. This affects prepared statements processed at the SQL level (using the PREPARE statement) and those processed using the binary client-server protocol (using the mysql_stmt_prepare() C API function). Previously, changes to metadata of tables or views referred to in a prepared statement could cause a server crash when the statement was next executed, or perhaps an error at execute time with a crash occurring later. For example, this could happen after dropping a table and recreating it with a different definition. Now metadata changes to tables or views referred to by prepared statements are detected and cause automatic repreparation of the statement when it is next executed. Metadata changes occur for DDL statements such as those that create, drop, alter, rename, or truncate tables, or that analyze, optimize, or repair tables. Repreparation also occurs after referenced tables or views are flushed from the table definition cache, either implicitly to make room for new entries in the cache, or explicitly due to FLUSH TABLES. Repreparation is automatic, but to the extent that it occurs, performance of prepared statements is diminished. Table content changes (for example, with INSERT or UPDATE) do not cause repreparation, nor do SELECT statements. An incompatibility with previous versions of MySQL is that a prepared statement may now return a different set of columns or different column types from one execution to the next. For example, if the prepared statement is SELECT * FROM t1, altering t1 to contain a different number of columns causes the next execution to return a number of columns different from the previous execution. Older versions of the client library cannot handle this change in behavior. For applications that use prepared statements with the new server, an upgrade to the new client library is strongly recommended. Along with this change to statement repreparation, the default value of the table_definition_cache system variable has been increased from 128 to 256. The purpose of this increase is to lessen the chance that prepared statements will need repreparation due to referred-to tables/views having been flushed from the cache to make room for new entries. A new status variable, Com_stmt_reprepare, has been introduced to track the number of repreparations. (Bug#27420: http://bugs.mysql.com/27420, Bug#27430: http://bugs.mysql.com/27430, Bug#27690: http://bugs.mysql.com/27690) * Important Change: Some changes were made to CHECK TABLE ... FOR UPGRAD
MySQL 5.1.25-rc has been released
Dear MySQL users, We are proud to present to you the MySQL Server 5.1.25-rc release, a new "release candidate" version of the popular open source database. Bear in mind that this is still a "candidate" release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.0, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ The MySQL 5.1.25-rc 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 the changes from version to version in the MySQL source code since the latest released version of MySQL 5.1, the MySQL 5.1.24-rc release. It can also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-25.html Sincerely, Timothy Smith The MySQL build team at Sun Microsystems News from the ChangeLog: Functionality added or changed: * Incompatible Change: A change has been made to the way that the server handles prepared statements. This affects prepared statements processed at the SQL level (using the PREPARE statement) and those processed using the binary client-server protocol (using the mysql_stmt_prepare() C API function). Previously, changes to metadata of tables or views referred to in a prepared statement could cause a server crash when the statement was next executed, or perhaps an error at execute time with a crash occurring later. For example, this could happen after dropping a table and recreating it with a different definition. Now metadata changes to tables or views referred to by prepared statements are detected and cause automatic repreparation of the statement when it is next executed. Metadata changes occur for DDL statements such as those that create, drop, alter, rename, or truncate tables, or that analyze, optimize, or repair tables. Repreparation also occurs after referenced tables or views are flushed from the table definition cache, either implicitly to make room for new entries in the cache, or explicitly due to FLUSH TABLES. Repreparation is automatic, but to the extent that it occurs, performance of prepared statements is diminished. Table content changes (for example, with INSERT or UPDATE) do not cause repreparation, nor do SELECT statements. An incompatibility with previous versions of MySQL is that a prepared statement may now return a different set of columns or different column types from one execution to the next. For example, if the prepared statement is SELECT * FROM t1, altering t1 to contain a different number of columns causes the next execution to return a number of columns different from the previous execution. Older versions of the client library cannot handle this change in behavior. For applications that use prepared statements with the new server, an upgrade to the new client library is strongly recommended. Along with this change to statement repreparation, the default value of the table_definition_cache system variable has been increased from 128 to 256. The purpose of this increase is to lessen the chance that prepared statements will need repreparation due to referred-to tables/views having been flushed from the cache to make room for new entries. A new status variable, Com_stmt_reprepare, has been introduced to track the number of repreparations. (Bug#27420: http://bugs.mysql.com/27420, Bug#27430: http://bugs.mysql.com/27430, Bug#27690: http://bugs.mysql.com/27690) * Important Change: Some changes were made to CHECK TABLE ... FOR UPGRADE and REPAIR TABLE with respect to detection and handling of tables with incompatible .frm files (files created with a different version of the MySQL server). These changes also affect mysqlcheck because that program uses CHECK TABLE and REPAIR table, and thus also mysql_upgrade because that program invokes mysqlcheck. + If your table was created by a different version of the MySQL server than the one you are currently running, CHECK TABLE ... FOR UPGRADE indicates that the table has an .frm file with an incompatible version. In this ca
Re: accumulating query
> I have reproduced this on two Windows 2000 boxes. What's going on? Why do > I keep adding on to the result set? When I drop back down to 4.0.13 this > problem disappears! Is this a bug in 4.0.18? Bruce, this is curious. To help us reproduce this, can you either upload the table in question to ftp.mysql.com:/pub/mysql/Incoming, along with a text file that describes the problem; or create a self-contained test case (including CREATE TABLE, INSERT and SELECT statements) that reliably causes this behavior for you? If you can do that, submit a bug report via bugs.mysql.com. If this won't work for you, let us know so we can pursue this further. Tim -- -- MySQL Users Conference April 14-16, 2004 http://www.mysql.com/uc2004/ -- -- Tim Smith, Support Engineer Cortez, Colorado, USA -- MySQL AB, www.mysql.com Office: 1-970-739-3489 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL server for Sun Solaris i386?
On 2001 Aug 09, Jeff Tanner <[EMAIL PROTECTED]> wrote: > I have downloaded http://www.mysql.com/downloads/mysql-3.23.html Sun Solaris > (Sparc) [sun-solaris2.7-sparc] to a Sun Solaris x86 machine. > > Mr. Milivojevic, would not the binaries Sun Solaris (Sparc) be not > compatible for Sun Solaris (x86)? No, they are not compatible. Different architectures => different instruction set => different binaries! > Mr. Smith, after building on a Sun Solaris x86 machine, the mysql build > fails when it trys to make files with suffixes of "*.cc". > > What am I missing? Good question. From that info, all I can guess is that your C++ compiler isn't working right. Did you check our Solaris notes in the manual? Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Timezone problem.
> > The small problem in mysql is it does not check if parameter is > > correct in configure script - this produced the problem... > > Peter mailto:[EMAIL PROTECTED] Yes, I don't know of any clear way of handling this with autoconf. Basically, if your option starts with "--with-", then the script just sets a variable and moves on. If anyone knows a good way to validate --with- and --enable- options in an autoconf-generated configure script, let me know. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Crash on replace
On 2001 Aug 03, Miguel Angel Solórzano <[EMAIL PROTECTED]> wrote:
> I was be able to repeat your bug report. Thanks and it
> will be fixed.
This has been fixed in the current code. Here is a
patch:
*** sql/ha_berkeley.cc.orig Fri Aug 3 09:46:50 2001
--- sql/ha_berkeley.cc Fri Aug 3 09:46:55 2001
***
*** 1201,1207
if (!(error=key_file[keynr]->cursor(key_file[keynr], trans,
&tmp_cursor, 0)))
{
! if (!(error=cursor->c_get(tmp_cursor,
(keynr == primary_key ?
prim_key :
create_key(&key, keynr, key_buff2, record)),
--- 1201,1207
if (!(error=key_file[keynr]->cursor(key_file[keynr], trans,
&tmp_cursor, 0)))
{
! if (!(error=tmp_cursor->c_get(tmp_cursor,
(keynr == primary_key ?
prim_key :
create_key(&key, keynr, key_buff2, record)),
Tim
--
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer
/_/ /_/\_, /___/\___\_\___/ Boone, NC USA
<___/ www.mysql.com
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: solairs 8 x86 get signal 11 with bdb support
On 2001 Jul 23, [EMAIL PROTECTED] wrote: > >Description: > Whenever I compile mysql 3.23.40 with Berkeley DB support, > I get a signal 11 when attempting to start the mysql server. > If I omit Berkeley DB support, everything starts fine. > >Synopsis:solairs 8 x86 get signal 11 with bdb support > >Release: mysql-3.23.40 (Source distribution) Brian, I'm not sure how well Berkeley DB is supported on x86 Solaris. Can you try running some of the programs inside the bdb/build_unix directory, to see if they crash or if they work? If they also crash, then something is wrong with the way bdb is being built. You might try getting a stock BerkeleyDB from sleepycat.com; if it works and ours doesn't, then clearly there is something wrong with how we're building ours. For example, try running 'db_printlog -V', to see if it prints out its version. Another thing to do is to pass the --with-debug flag to configure when you build MySQL, and run mysqld under a debugger to find out exactly where it crashes. You can find detailed instructions on how to do this in our manual: http://www.mysql.com/doc/D/e/Debugging_server.html If you could do this, it would help us a lot! Thanks, Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Help on cross table Query
On 2001 Jul 10, Yan Zhang <[EMAIL PROTECTED]> wrote: > Please help me here, and let me know if MySQL can do it or not. All people > around me told it should work in SyBASE. Please don't spam! Use *one* e-mail address that is appropriate. This is on our list of things to do, probably in version 4.1. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Oddity with building 3.23.38 on Tru64 4.0f
On 2001 Jun 20, Michael Widenius <[EMAIL PROTECTED]> wrote: > > Tim, what do you think if we rename our own copy of bdb with 'libmy-bdb' > just to ensure that we link with our copy of bdb ? I think this is a good idea. libdb is everywhere, and it's too easy to make a mistake. I'll add it to my list of things to do. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-time Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Need Japanese character set files
On 2001 Jun 06, Anatole <[EMAIL PROTECTED]> wrote: > > I brought down mysqld and restarted as before with safe_mysqld > --default-character-set=sjis and get the following error message when php > tries to connect: > > Can't initialize character set 13 (path: default) in > /usr/local/apache/sites/gaijinpot.com/php/common.inc Ah, the vital clue. You're using PHP, and probably used the mysql that is bundled with PHP (an older version, too), and not an external MySQL library. The PHP version only comes with the latin1 character set. What you need to do is configure PHP using their --with-mysql=/path/to/your/mysql option, and make and install the new PHP. Yes, this is kind of a pain, but that's how it goes. If you have trouble with this process, a PHP list is probably the best place to get help. Oh, you might be able to get around this by just using the most recent version of PHP. We added a hack to ignore the error you are getting, since the client doesn't have to do much with the character sets. But I'm not sure if it will work when the server is using a multi-byte character set - it might just break. The way to be sure that things work is to follow my instructions above. If you just upgrade your PHP, and things don't work, let me know the error you get so maybe I can find a work-around. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Development Team /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Need Japanese character set files
On 2001 Jun 06, Anatole <[EMAIL PROTECTED]> wrote: > > I installed MySQL from an RPM file on Linux. When I use the mysql>show > variables like 'character_sets'; as you mentioned above, I do, indeed, show > sjis. This means that the sjis character set is compiled into the server already, so you do not need to recompile MySQL in order to use the sjis character set. > So, I shutdown mysql and restarted it like this: > safe_mysqld --default-character-set=sjis > > This resulted in an error message (sorry I forgot the one however something > it to do with missing charsets I believe). I would need to know the error message in order to guess what is going wrong. > I had a look around and I noticed the following charsets in > /usr/share/mysql/charsets: > Alas, no sjis, but I imagine that is because it a double-byte character set. Yes. If you had the source distribution, you would see the file called strings/ctype-sjis.c, which contains the code needed to handle the sjis character set. > So, I'm left with the following question: > 1. What do you mean by > >More complex character sets must > > be compiled into the server. In order to use the more complex character sets, such as sjis, extra code must be linked into the mysqld binary. When we build our binary distributions, we do link in the extra code for all of the more complex character sets. > And how would I go about doing this? You do not need to do this, since you are using a standard binary that already includes all of the more complex character sets. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Development Team /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Help us make MySQL better
MySQL is taking a survey of MySQL users. As a bribe to get more people to fill out the survey, we are giving away three Palm PDAs and ten autographed MySQL books. Please take about ten minutes to fill out the web page: http://www.mysql.com/survey/ MySQL is an Open Source Database Server. Anyone can download it from our website, use it and pass it along to friends and associates. This means that we, the core developers and others at MySQL AB, don't really know who is using MySQL and for what. We need this information to help us develop MySQL to suit future needs. This information will also help us know what services we may sell to support our development work. You can provide this, so please help us! We will give three randomly-chosen persons filling out our survey a color Palm Pilot IIIc and ten others a copy of Paul DuBois' best-selling MySQL book, autographed by Michael "Monty" Widenius and the rest of the MySQL Development Team. Winners will be drawn on Monday July 16, 2001. All winners will be notified personally by email. We really do appreciate your taking the time to do this. If you know of anyone using MySQL who probably didn't get this message, you might forward the above URL to them as a favor to us. With Kind Regards, Tim, for the MySQL team -- Need MySQL help? https://order.mysql.com/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Fulltime Developer /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Need Japanese character set files
On 2001 Jun 04, Narendra Phadke <[EMAIL PROTECTED]> wrote: > > I am storing Japanese data inside MySQL. > MySQL supports all the Europian languages and other languages like korian > and Hebru, and you have all the character set files for all these languages > inside the C:\mysql\share\charsets directory. > But this directory does not contain Japanese character set files. Where can > I get these files? Only single-byte character sets with simple sorting rules can be described by the *.conf files. More complex character sets must be compiled into the server. The binaries that MySQL distributes have all supported character sets included. You can see what character sets are available with this command: mysql> show variables like 'character_sets'; You should notice ujis and sjis there, if you are using one of our binaries. If you compile MySQL yourself, you must specify the character sets you want when you run 'configure', like this: sh configure --with-charset=sjis --with-extra-charsets=ujis,gbk When you start mysqld, you use the --default-character-set=ujis option to change the character set being used. Our binaries use latin1 by default. With the configuration line from above, the default would be sjis, but you could specify ujis, gbk, or any of the simple character sets in share/charsets/*.conf. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Development Team /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Update bug?
On 2001 Apr 13, Maciek Dobrzanski <[EMAIL PROTECTED]> wrote: > > This is because with the first query it can use the index. With > > the second query, it has to check the whole table. Why? Because > > obviously you're using numbers. And let's make some_value == 10. > > I thought that maybe MySQL should check the field type and do the conversion > to string. To which string? '10' or ' 10' or '010', ...? One thing that might work in this case is to only scan the ranges ['0' - '1'], [' ' - '!'] and an exact match. Something like that. But it's messy, and best to fix the application. It would be nice if MySQL could optimize even the worst queries, though. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Development Team /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Update bug?
On 2001 Apr 13, Maciek Dobrzanski <[EMAIL PROTECTED]> wrote: > | fd_10 | varchar(20) | | MUL | | | > | fd_11 | varchar(20) | | | | | > > Now when I do this update: > UPDATE test SET fd_11='value' WHERE fd_10='some_value' > it usually executes in 0.00 sec > > But when the query looks like this: > UPDATE test SET fd_11='value' WHERE fd_10=some_value > It takes about 2 seconds to execute. This is because with the first query it can use the index. With the second query, it has to check the whole table. Why? Because obviously you're using numbers. And let's make some_value == 10. In the second query it has to check for rows where fd_10 is: '10' '010' '0010' ... If you're storing numbers, use a numerical column. If you're testing a varchar field, use a string. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Development Team /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: bug report - docs
On Sun, Apr 08, 2001 at 12:22:32PM -0500, Rodrigo Zerlotti wrote: > > >Description: > INSTALL-BIN file has errors: > > shell> chown -R mysql /usr/local/mysql/var > > it should be > > chown -R mysql /usr/local/mysql/data > > instead "var" Thanks, Rodrigo. I have fixed it now. Tim -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Tim Smith <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Development Team /_/ /_/\_, /___/\___\_\___/ Boone, NC USA <___/ www.mysql.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
