MySQL 5.1 Released, Not Quite Up To Par

Mad Merlin writes "It's no secret that MySQL 5.1 has been a long time in the making, with the first beta release being in Nov 2005, but MySQL 5.1.30 has finally been released as GA. MySQL users can expect new features such as table/index partitioning, row based replication, a new plugin architecture, an event scheduler and a host of performance improvements from 5.1." Monty also had a blog post outlining some of the challenges faced in 5.1, including crashing bugs and a beta quality to most new features.

Comments

5.0? that so?

[toby]

I've been using 5.0 in production for well over a year and found no 'critical' bugs. (For most of that time I had access to MySQL's paid support.)

As Ryan said there is no such thing as bug free software but there is such a thing as production-ready software. MYSQL 5.0 HAZ IT.

Re:Wow

[TheRaven64]

MySQL is very easy to use and configure the first time. Postgres isn't nearly as simple

I've heard this a few times. I've installed PostgreSQL on Windows, Linux, FreeBSD and OpenBSD. Every time, the process has been:

1. Install from the package
2. Run initdb to initialise a new storage location (sometimes done by the package - I think it was under RedHat).
3. Run createuser and createdb for each DB user and each DB that needed to exist.

How does MySQL simplify this?

Re:Not a question forum

[Muad'Dave]

Uh, if you're trying to interrogate a BLOB column on a particular row that you have criteria for, wouldn't this work?

select count(myblob) from myTable where field1='criterion1' and field2='criterion2' ... and myBlob is not null

If it returns 1, the column has data. If it returns 0, it's null.

Re:Wow

[larry bagina]

One thing I like about postgresql vs MS Sql is the triggers. MS SQL triggers are after-insert, per statement only, IIRC. Pg triggers are per statement or per row, before or after. There's also a rule system and the ability to rewrite the query, for updateable views or other tricks. The lacking features are clustered indexes, replication, and partitioning. I'll also mention hash indexes -- it has them, but they're not journaled, and they're not generally recommended. I'm not going to comment on MySQL since I haven't used it since 4.x and it sort of has triggers now.

Oh, also, the pgpsql stored procedure language is similar to oracle's psql and fairly fun to program in.

Re:MySQL x.1 releases gives me the creeps

[Anonymous Coward]

So, you're waiting for MySQL 5.11 for Workgroups?

Re:Wow

[jmusits]

.... Things like "SHOW TABLES" are either considerably more difficult in Postgres or harder to find out. ....

More difficult? Harder to find out? Consult help by typing \? and you will see this:
[snip]
Informational
    \d [NAME] describe table, index, sequence, or view
    \d{t|i|s|v|S} [PATTERN] (add "+" for more detail)
                                  list tables/indexes/sequences/views/system tables
[snip]

Then type \dt to show the tables. To me that does not present it seld as more difficult or hard to find out.

Re:news flash

[Fahrvergnuugen]

Almost right. Oracle owns InnoDB, which is the useful part of MySQL.

Re:Wow

[moderatorrater]

That's only using the client which hides the actual queries from you. If connecting through code, \dt doesn't work; in mysql, show tables does.

Re:well

[nabsltd]

To step away from the metaphor for a second - I have had severity 1 service tickets open with Oracle support for over a day that ended up being unpublished bugs that were fixed with a patch that was not available until you knew you had run into the bug. Sev 1 to be clear is production systems down.

I'll second this. We just ran into such a bug when trying to restore a database.

The application connecting to the database was upgraded, and something went wrong when it tried to modify the schema, so we rolled back to the backup taken immediately before the start of this. Normally, this would have been simple, but apparently there's a bug with our version of Oracle that caused the restore to fail. Luckily, it only took an extra couple of hours to work around and we were still in our planned outage window, but it still sucked that it was a bug known to Oracle.

Of course, we didn't hit the Oracle bug in our development and test systems, because the application didn't fail in the schema update on those, thank's to Mr. Murphy.

Re:The first time I used MySQL...

[Michael Wardle]

So you'll know for next time...

On top of that, passwords are apparently specific to a certain host string. Bizarre. Do I need to use localhost for the actual machine name for local users? What about remote machine without a reverse DNS entry? What's the order of precedence for '%' vs a more specific name?

The manual seems to describe this in the connection access and request access sections. It answers your question on precedence (most specific to least specific, first match wins), but not the others. You would assume that localhost or 127.0.0.1 would work for connections initiated over the loopback interface (i.e. where the client application connects to localhost or 127.0.0.1), but that you would need to use the real public host name if the application is connecting via that. That's how networking works. Interesting point about reverse name lookups not working. Hopefully it's getting the name from there, and not just using whatever hostname the client asserts when it connects. You'd want to use IP addresses rather than host names to be safer. They mention that wildcard and host/subnet notation is supported.

Okay, so to change [the root password] do I use root@% or root@computer? How do I know I changed the right one and there isn't still some root@something entry? SHOW TABLES is easy enough, how about SHOW USERS? Nope, that's not it.

Well, you now know the precedence. The pages I linked to before also tell you that MySQL determines these based on the values in the user table (i.e. mysql.user), so you could just do a SELECT * FROM user WHERE User = 'root' to see what entries exist. From there, you would either have noticed that the passwords were hashed, and so found the password hashing section and executed an UPDATE user SET PASSWORD = PASSWORD(password) WHERE..., or you would have found the SET PASSWORD documentation, or a quick Google search would likely have yielded the more common advice to just do mysqladmin -u root password NEWPASSWORD.

Re:Wow

[Zontar The Mindless]

... master/master replication is buggy and will frequently just stop replicating in one direction or the other. It's easy enough to fix (once you've learned how...the documentation could be a lot more thorough), but it's annoying that we have to do it so frequently.

You can also file bugs against the docs (Category is "MySQL Server:Documentation"). Please do so.

It would help resolve the issue more quickly if you could supply at least some of the information that you think is missing.

Thanks for helping other MySQL users!