Mysql Upgrade to 3.23.58 issue in Fedora Core 2
Hello I ram yum update for mysql , mysql-server and mysql-devel in fedora core 2, after this mysql is not starting. === Log Error message: 080715 22:55:58 mysqld started Cannot initialize InnoDB as 'innodb_data_file_path' is not set. If you do not want to use transactional InnoDB tables, add a line skip-innodb to the [mysqld] section of init parameters in your my.cnf or my.ini. If you want to use InnoDB tables, add to the [mysqld] section, for example, innodb_data_file_path = ibdata1:10M:autoextend But to get good performance you should adjust for your hardware the InnoDB startup options listed in section 2 at http://www.innodb.com/ibman.html 080715 22:55:58 /usr/libexec/mysqld: Incorrect information in file: './mysql/host.frm' 080715 22:55:58 mysqld ended mysql starts after I moved /var/lib/mysql folder then created new one, then /etc/init.d/mysql start Installed new packages mysql-3.23.58-16.FC2.1 mysql-server-3.23.58-16.FC2.1 mysql-devel-3.23.58-16.FC2.1 mod_auth_mysql-20030510-5 php-mysql-4.3.11-1.fc2.3.legacy.1.swsoft -- Regards Sudheer M.T IT Administrator Open Clovis Solutions. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Issue with mysql 3.23.58 in fedora core 2
I found this in innodb log file.. Version: '4.1.9-standard' socket: '/var/lib/mysql/mysql.sock' port: 3306 Official MySQL RPM 080712 04:37:21 mysqld started 080712 4:37:29 [Warning] Asked for 196608 thread stack, but got 126976 080712 4:37:36 InnoDB: Started; log sequence number 0 9344234 080712 4:37:40 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run /usr/sbin/mysqld: ready for connections. Version: '4.1.9-standard' socket: '/var/lib/mysql/mysql.sock' port: 3306 Official MySQL RPM 080712 4:37:45 [Note] /usr/sbin/mysqld: Normal shutdown I am facing problem, after I ram yum update mysql-server on fedora core 2. -- Regards Sudheer M.T IT Administrator Open Clovis Solutions. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Help requested to provide bug reports for 5.1
Hi! This is a request to all MySQL users to help mysql developers, by providing information, so that we can help you, by providing a more stable MySQL server for your needs. As you may know, MySQL 5.1 has been in state of release candidate (RC) for some time. The last RC was announced as the last RC and is supposed to be followed by a GA release. The GA release is planned to be the exact same code as the last GA, only with the label changed. The question we, who are developing and supporting the MYSQL server have been asking ourselves is, Are really now in shape to do a proper GA release?. We would like you as a MySQL User to help us out with deciding this. We don't want to repeat the mistake we did with MySQL 5.0 GA and then again with MySQL 5.1 RC, by releasing a MySQL 5.1 GA too early. Our external criteria for General Availability (GA) or Production release can be found here: http://dev.mysql.com/doc/refman/5.1/en/choosing-version.html What you may not know is that we have as part of our internal GA criteria, a requirement that we should not have any serious bugs, crashing or wrong result bugs, that affects a notable amount of users. The criteria states that it is ok to postpone fixes for bugs that have a low impact (ie affects few users). This has the following implications: - Bugs for which we don't have many user/customer reports for are not likely to get fixed. (In the worst case not even in 6.0 !) - It's ok to go out with bugs in new feature in the GA as long as we don't have many users/customers that have reported problems with these features. In other words, if you have an issue with a serious bug that exists in 5.1 that you *really* would like to have fixed soon now is your chance to influence our development! Note that it's ok, and we want, you to also report bugs after we release the MySQL 5.1 as GA. The more users/customers commenting on a bug the more chance it will be fixed! What I would like for people to do: - Report every single bug that you encounter or know about in 5.1 into our bugs system. http://bugs.mysql.com/ - If the bug is already reported, please add a comment to the bug report that it affects you too. - If you are a MySQL support customer, add either a note to the bug report that you are a customer and the bug affects you or send a request as a customer directly to the MySQL support personal (they are happy to take your reports!) - If you have reported a bug a long time ago that has not been fixed and this is still important for you to get fixed, please reopen the bug/add a note in the bugs database that the bug is still relevant for you! Note that you should also do this for bugs that you know of in MySQL 5.0 that are still open for MySQL 5.1 (or any bugs that are labelled to be fixed in a future release). Bugs that are in earlier version are also very likely to also be in 5.1 if the bugs database doesn't say otherwise. Lets make the MySQL server bugs life's harder by giving us more information about which bugs are really important for us to fix. More information will help us make better decisions about how and when a bug should be fixed. You can find the above text also at: http://monty-says.blogspot.com/ Regards, Monty Founder of MySQL -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
default, Nullable and NULL : confused
Hello, I do not understand the behavior of a simple table : from what I red, in the following exemple the Null column tells the value can be set to NULL, and the Default value is NULL. It doesn't seem to work that way. Some one could explain it ? I run on a linux debian/etch 5.0.32 MySQL release. I have a table named t like : mysql describe t; +---++--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +---++--+-+-+---+ | n | double | YES | | NULL| | | c | varchar(5) | YES | | NULL| | +---++--+-+-+---+ Now I load data infile like this : load data infile'/data/foo' into table t fields terminated by';'; with /data/foo containing : 0.12345;qwer 1.2345; ;asdf I get Records: 3 Deleted: 0 Skipped: 0 Warnings: 1 mysql show warnings; +-+--++ | Level | Code | Message| +-+--++ | Warning | 1265 | Data truncated for column 'n' at row 3 | +-+--++ from now, I expect to have NULL where the fields are empty, but instead I get '' in the 2nd row, columb 'c' '0' in the last row, column 'n' mysql select * from t; +-+--+ | n | c| +-+--+ | 0.12345 | qwer | | 1.2345 | | | 0 | asdf | +-+--+ mysql select * from t where c is null or n is null; Empty set (0.00 sec) For my purpose, '0' , '' and NULL Thank you for any help. regards, _-¯-_-¯-_-¯-_-¯-_ Gilles Missonnier IAP - [EMAIL PROTECTED] 01 44 32 81 36 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Help requested to provide bug reports for 5.1
Can MySQL share the results of performance testing that has been done to compare 5.1 with 5.0? On Wed, Jul 16, 2008 at 3:13 PM, Michael Widenius [EMAIL PROTECTED] wrote: Hi! This is a request to all MySQL users to help mysql developers, by providing information, so that we can help you, by providing a more stable MySQL server for your needs. As you may know, MySQL 5.1 has been in state of release candidate (RC) for some time. The last RC was announced as the last RC and is supposed to be followed by a GA release. The GA release is planned to be the exact same code as the last GA, only with the label changed. The question we, who are developing and supporting the MYSQL server have been asking ourselves is, Are really now in shape to do a proper GA release?. We would like you as a MySQL User to help us out with deciding this. We don't want to repeat the mistake we did with MySQL 5.0 GA and then again with MySQL 5.1 RC, by releasing a MySQL 5.1 GA too early. Our external criteria for General Availability (GA) or Production release can be found here: http://dev.mysql.com/doc/refman/5.1/en/choosing-version.html What you may not know is that we have as part of our internal GA criteria, a requirement that we should not have any serious bugs, crashing or wrong result bugs, that affects a notable amount of users. The criteria states that it is ok to postpone fixes for bugs that have a low impact (ie affects few users). This has the following implications: - Bugs for which we don't have many user/customer reports for are not likely to get fixed. (In the worst case not even in 6.0 !) - It's ok to go out with bugs in new feature in the GA as long as we don't have many users/customers that have reported problems with these features. In other words, if you have an issue with a serious bug that exists in 5.1 that you *really* would like to have fixed soon now is your chance to influence our development! Note that it's ok, and we want, you to also report bugs after we release the MySQL 5.1 as GA. The more users/customers commenting on a bug the more chance it will be fixed! What I would like for people to do: - Report every single bug that you encounter or know about in 5.1 into our bugs system. http://bugs.mysql.com/ - If the bug is already reported, please add a comment to the bug report that it affects you too. - If you are a MySQL support customer, add either a note to the bug report that you are a customer and the bug affects you or send a request as a customer directly to the MySQL support personal (they are happy to take your reports!) - If you have reported a bug a long time ago that has not been fixed and this is still important for you to get fixed, please reopen the bug/add a note in the bugs database that the bug is still relevant for you! Note that you should also do this for bugs that you know of in MySQL 5.0 that are still open for MySQL 5.1 (or any bugs that are labelled to be fixed in a future release). Bugs that are in earlier version are also very likely to also be in 5.1 if the bugs database doesn't say otherwise. Lets make the MySQL server bugs life's harder by giving us more information about which bugs are really important for us to fix. More information will help us make better decisions about how and when a bug should be fixed. You can find the above text also at: http://monty-says.blogspot.com/ Regards, Monty Founder of MySQL -- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- Mark Callaghan [EMAIL PROTECTED]
Re: Help requested to provide bug reports for 5.1
(sending again without html encoding) Can MySQL share the results of performance testing that has been done to compare 5.1 with 5.0? On Wed, Jul 16, 2008 at 3:13 PM, Michael Widenius [EMAIL PROTECTED] wrote: Hi! This is a request to all MySQL users to help mysql developers, by providing information, so that we can help you, by providing a more stable MySQL server for your needs. As you may know, MySQL 5.1 has been in state of release candidate (RC) for some time. The last RC was announced as the last RC and is supposed to be followed by a GA release. The GA release is planned to be the exact same code as the last GA, only with the label changed. The question we, who are developing and supporting the MYSQL server have been asking ourselves is, Are really now in shape to do a proper GA release?. We would like you as a MySQL User to help us out with deciding this. We don't want to repeat the mistake we did with MySQL 5.0 GA and then again with MySQL 5.1 RC, by releasing a MySQL 5.1 GA too early. Our external criteria for General Availability (GA) or Production release can be found here: http://dev.mysql.com/doc/refman/5.1/en/choosing-version.html What you may not know is that we have as part of our internal GA criteria, a requirement that we should not have any serious bugs, crashing or wrong result bugs, that affects a notable amount of users. The criteria states that it is ok to postpone fixes for bugs that have a low impact (ie affects few users). This has the following implications: - Bugs for which we don't have many user/customer reports for are not likely to get fixed. (In the worst case not even in 6.0 !) - It's ok to go out with bugs in new feature in the GA as long as we don't have many users/customers that have reported problems with these features. In other words, if you have an issue with a serious bug that exists in 5.1 that you *really* would like to have fixed soon now is your chance to influence our development! Note that it's ok, and we want, you to also report bugs after we release the MySQL 5.1 as GA. The more users/customers commenting on a bug the more chance it will be fixed! What I would like for people to do: - Report every single bug that you encounter or know about in 5.1 into our bugs system. http://bugs.mysql.com/ - If the bug is already reported, please add a comment to the bug report that it affects you too. - If you are a MySQL support customer, add either a note to the bug report that you are a customer and the bug affects you or send a request as a customer directly to the MySQL support personal (they are happy to take your reports!) - If you have reported a bug a long time ago that has not been fixed and this is still important for you to get fixed, please reopen the bug/add a note in the bugs database that the bug is still relevant for you! Note that you should also do this for bugs that you know of in MySQL 5.0 that are still open for MySQL 5.1 (or any bugs that are labelled to be fixed in a future release). Bugs that are in earlier version are also very likely to also be in 5.1 if the bugs database doesn't say otherwise. Lets make the MySQL server bugs life's harder by giving us more information about which bugs are really important for us to fix. More information will help us make better decisions about how and when a bug should be fixed. You can find the above text also at: http://monty-says.blogspot.com/ Regards, Monty Founder of MySQL -- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- Mark Callaghan [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: default, Nullable and NULL : confused
in your data file use this for inserting null values '\N' 0.12345;qwer 1.2345;\N \N;asdf On 7/17/08, Gilles MISSONNIER [EMAIL PROTECTED] wrote: Hello, I do not understand the behavior of a simple table : from what I red, in the following exemple the Null column tells the value can be set to NULL, and the Default value is NULL. It doesn't seem to work that way. Some one could explain it ? I run on a linux debian/etch 5.0.32 MySQL release. I have a table named t like : mysql describe t; +---++--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +---++--+-+-+---+ | n | double | YES | | NULL| | | c | varchar(5) | YES | | NULL| | +---++--+-+-+---+ Now I load data infile like this : load data infile'/data/foo' into table t fields terminated by';'; with /data/foo containing : 0.12345;qwer 1.2345; ;asdf I get Records: 3 Deleted: 0 Skipped: 0 Warnings: 1 mysql show warnings; +-+--++ | Level | Code | Message| +-+--++ | Warning | 1265 | Data truncated for column 'n' at row 3 | +-+--++ from now, I expect to have NULL where the fields are empty, but instead I get '' in the 2nd row, columb 'c' '0' in the last row, column 'n' mysql select * from t; +-+--+ | n | c| +-+--+ | 0.12345 | qwer | | 1.2345 | | | 0 | asdf | +-+--+ mysql select * from t where c is null or n is null; Empty set (0.00 sec) For my purpose, '0' , '' and NULL Thank you for any help. regards, _-¯-_-¯-_-¯-_-¯-_ Gilles Missonnier IAP - [EMAIL PROTECTED] 01 44 32 81 36 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
