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.
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.
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.
- 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!
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.
Posts
9 comments:
The one thing that is holding me back in testing MySQL 5.1 RC is the horribe state of the installers for mysql on Mac OS X. I (and anybody else I know) had a hard time getting MySql 5 (5.0.51a) installed properly on Mac OS X (10.5) and I don't want to waste time again trying to get a new MySQL to work if I can avoid it.
Here's a nasty that has existed since information_schema was introduced in 5.0: http://bugs.mysql.com/bug.php?id=29153
SHOW and infoschema use LONGTEXT columns, so the temporary table that is internally created cannot be type MEMORY.
Since most people's default is MyISAM, the table goes to disk, making infoschema excruciatingly slow.
A full list of which infoschema tables use this type is included in the bug report.
Infoschema is sooooo useful, but also soooo unusable on servers with more databases/tables/columns as it's just too slow, and this issue is a major factor.
MySQL 5.0 has support for VARCHAR up to nearly 64k, so these columns could be changed to varchars. The exact value is not that important, you can even just put in the maximum and it would still perform better than what it is now!
Please add the Spatial Functions from 5.1.23-gis (forge) to MySQL 5.1-GA
http://forge.mysql.com/wiki/GIS_Functions
Found this bug with SAVEPOINT last week: http://bugs.mysql.com/bug.php?id=38187
It affects me pretty badly since I use savepoints in all stored procedures to handle local errors. Each SP updates 2-5 tables, and needs to be able to rollback it's own chances if something goes wrong without affecting the applications "broader" transaction.
Anyone that uses savepoints is potentially affected by this bug.
Hello,
Downloading the release. ;)
I hope that a new versions of MySQL Server have a utilities or systems for Bussines Intelligence, It'll be great for this technologies.
The best regards
Gildus
We've got sth around 60 mysql 5.0.x database servers running all the time on production and every month there is some problem with mysql bug. Recently it got locked forever (for 20 hours) even though there were no queries shown by mysqladmin processlist (it couldn't even do a simple select * from X limit 1 (X being innodb table); and it wasn't the case of lacking unlock tables on connection).
For me any mysql 5.0.x is still a great example of unreliable database.
There is a huge Bug in MySQL when you are using id's with auto-increment. When you put in 3 entries in the db and than delete 1 entry. If you now add a new entry it gets the id 4. So the autoincrement can only count up, but not down. So you have to delete the primary key and than recreate it. So the autoinkrement has no holes and reaches the maximum count only if you really have so much entries.
We need a function for that, because that what i am doing is only a workaround but it works fine.
thx for reading my poor english ;)
It's intentionally that auto-increment can't count down: This is how autoincrement and sequences work in most databases.
If it would count down, you would easily get serious problems with entries in other tables that refers to deleted rows, with replication and with multiple connections inserting and updating the same database.
If you set the auto-increment key to a long value, there basicly no chance a value will be reused (2^32 is a really big number).
About problems with 5.0:
To be able to help you, we would need some information where 5.0 hangs or a way to repeat it. The current 5.0 has been proven to be quite stable now, but there may of course be something unique in your setup that we don't know about.
You could try to setup a 5.1 server and see if this would help you; If you are only using 5.0 features, then 5.1 may be a better alternative for you.
Post a Comment