Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Mysql 5.0 AND 5.1 are EOL since 2013. Let's at least move the minimum to 5.1, which is widely supported.
Even RHEL is 5.1.61 at this point, Ubuntu 10.04 was 5.1.41 so 5.1.21 (released 2007-08-16) is not a problem any more (perhaps for D7 RHEL 5 was a concern).
For follow-up in #2348931: Use native MySQL statement preparation via PDO we should consider changing the way we handle prepared statements:
So says the MySQL manual:
Before MySQL 5.1.21, for a prepared statement executed using PREPARE and EXECUTE, it is not cached if it contains any ? parameter markers. In that case, the statement after parameter expansion contains references to user variables, which prevents caching, even for nonprepared statements. If the statement contains no parameter markers, the statement is compared with statements in the query cache that were executed using the text protocol (that is, it is compared with other SQL PS statements and nonprepared statements). As of MySQL 5.1.21, this limitation is lifted and prepared statements that contain parameter markers can be cached because expansion directly substitutes the user variable values.
Now, this would mean that we can keep prepared statements around and skip the SQL parsing overhead which can be quite big -- cache for example could be much faster if we could re-run the same prepared statement.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 1856262-10.patch | 467 bytes | pwolanin |
| #1 | 1856262_1.patch | 1.33 KB | chx |
| performance_1.patch | 1.28 KB | chx | |
Comments
Comment #1
chx CreditAttribution: chx commentedActually, it seems PDO might default to this so force it off.
Comment #3
David StraussI'm biased on this, considering that I run everything for myself and Pantheon on the latest Fedora, which is always super up-to-date on stuff like MySQL releases. I also believe Acquia uses Percona releases, even on their Ubunu 8.04 systems. Recent Percona releases should also support MySQL 5.1 features.
Emulating prepared statements is a wasteful thing for PDO to do. It'd be possible to support MySQL 5.0 without overhead for MySQL 5.1+ users by having the installer drop something into settings.php telling PDO to emulate prepared statements if MySQL 5.0 is what's present at install time. Still, I'd rather not support MySQL 5.0 at all.
Do we have a list of hosting providers we consider a foundation for compatibility?
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedDo we have any reason to believe that PDO emulation would be slower then MySQL prepared statements? I'm doubtful.
The usual idea behind prepared statements (at least on PostgreSQL, SQL Server, Oracle, etc.) is to allow the database to spend a little bit more time to optimize / come up with an optimal plan for the query, because the same query will be executed several times. In the case of PHP, the shared-nothing execution model means we almost never execute a prepared statement more then once. In that case, using native prepared statement is purely wasteful.
This needs benchmarks.
Comment #5
chx CreditAttribution: chx commentedThis is impossible to do. During drupal_flush_all_caches you will get:
You would think that PDO::MYSQL_ATTR_USE_BUFFERED_QUERY in the connection options helps? Nope, it needs to go on prepare but even I patched prepare to do it, I still got the error. The amount of refactor to fetchAll in all cases is not worth it.
Comment #5.0
chx CreditAttribution: chx commentedUpdated issue summary.
Comment #6
pwolanin CreditAttribution: pwolanin commentedI think we should take a look at this again, given that MySQL 5.1 is EOL since December 2013 with no updates being released:
https://www.mysql.com/support/eol-notice.html
At the very least, we should start bumping the minimum version from '5.0.15' to at least 5.1.x to avoid adding to our long-term testing and BC burden.
Comment #7
catchDon't think this is critical, unless the PHP emulation is critically bad in which case this needs an issue summary update to explain why.
Also this reminded me of #2301501: [policy, no patch] Explicitly decide and document that mininum requirements for major versions might get raised in minor versions - we should be prepared to raise minimum requirements when we put out minor releases. We already raised Drupal 6's to drop support for PHP 4.
Comment #8
pwolanin CreditAttribution: pwolanin commentedI think this is critical, since such a change seems to be the only way to begin approaching: #2348931: Use native MySQL statement preparation via PDO
Comment #9
pwolanin CreditAttribution: pwolanin commentedLet's simplify this issue and defer the question of emulating prepare or not to #2348931: Use native MySQL statement preparation via PDO
Comment #10
pwolanin CreditAttribution: pwolanin commentedComment #11
David StraussA big +1. The availability of muliple free and cheap platforms (and VMs, from IaaS providers) for running Drupal has removed any worries I have about supporting bad shared hosting providers with obsolete PHP or MySQL.
Comment #12
pwolanin CreditAttribution: pwolanin commentedIs 5.1.21 the right minimum, or should we go to e.g. 5.1.41 based on Ubuntu 10.04? That seems to be the lowest we'd consider? Debian Squeeze is 5.1.73.
Comment #13
chx CreditAttribution: chx commentedMySQL 5.1 is on sustain, to quote MySQL policy:
https://mariadb.com/kb/en/mariadb/development/mariadb-maintenance-policy/ says that the maintenance of 5.1 ends on 1 Feb 2015. (It's interesting to see what they mean by maintenance btw)
I can't even imagine anything older running in the wild when 5.1 is practically over.
Edit: finding the right minimum is pointless, isn't it?
Comment #15
webchickAgreed, as long as this is high enough to not hit the bug, as low as we can go seems like a good compromise.
Committed and pushed to 8.0.x. Thanks!