5.1.46 has this change:
Performance: While looking for the shortest index for a covering index scan, the optimizer did not consider the full row length for a clustered primary key, as in InnoDB. Secondary covering indexes will now be preferred, making full table scans less likely.
In other words, if you have covering index on * (which is quite common on m:n mapping tables), use it rather than PK. As I have spent my time getting indexing right and having PKs be based on primary access pattern and SKs on secondary access pattern, I hereby not welcome the new change that suddenly reverses the behavior in late GA version.
Not good, when mysqldump queries end up taking 6 days instead of previous half an hour, not good at all.
Update: Oh, MariaDB has this reverted, from their change log:
mybug:39653: reverted as invalid
If only upstream MySQL would take note ;-)
I feel ashamed that I ever wanted you to support 4.0->5.1 replication, and apologize for that. I really understand that it was really egoistic of me even to consider you should be involved in this.
I even understand that 5.0 is running out of active support (I’m not questioning that you’ll stop supporting 4.1 entirely too), and you’ll stop doing pretty much anything to 5.0, except “critical security fixes” (w00t, I managed to get one into 4.1, 8 year old MITM flaw :).
I really understand that supporting more than one release is very very very difficult, and people should do only adjacent version upgrade.
I’m not asking you much, but, maybe you could then support 5.1 to 5.1 replication? I don’t want much, just:
- Gracefully recover after slave crashes.
- Don’t have single serial reading of pages for replication stream as a bottleneck – either read-ahead properly (you can do that with RBR!!!), or apply events in parallel (you can do that with RBR too!)
- Allow to edit replication filters without restarting servers.
- Allow to enable and disable binary logging of events received from master, as well as enabling and disabling binary logging without restarting the instance.
I hope it isn’t too much too ask! It is just supported replication between two same version instances.
One immediately realizes Apple computers are very artsy, and why they’re loved by designers and such. Instead of showing BSODs, they start making abstract art.
Thats how it shows me my mail:
Wikipedia users did get nice errors like:
Fatal error: Call to undefined function: peplaceinternallinks() in
/usr/local/apache/common-local/php-1.5/includes/Parser.php on line 812
Table 'nlwiki.recemtchanges' doesn't exist (10.0.0.101)
UPDATE `recemtchanges` SET ...
In both cases code was absolutely normal and after rogue Apache servers (different ones!) were restarted, those glitches did disappear. No ECC errors reported… what should be blamed? OS? Hardware? Apache? PHP? APC? Ummm….