Hello everyone!
I've created a PR to send COM_RESET_CONNECTION in mysqlnd when
reusing a persistent connection [1]. This ensures that the connection
is in a blank-slate state, and not possibly in a transaction or
operating with any variables set from a previous request, etc.
Tim had opened a GitHub issue for this a while back [2]. A user
commented there to point out that COM_RESET_CONNECTION is supported
in MySQL 5.7.3+ and MariaDB 10.2+, and so my implementation would
necessitate at least those versions as a minimum supported version.
Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think. Notably, if we were to
implement configuration for this we'd likely need to introduce yet
another INI variable; I have an impression that PHP maintainers are
somewhat skeptical of adding new INI settings.
Secondly, I'm curious what people think about implementing this in
both PDO and mysqlnd. In PDO, we can replace the liveness check
with this command, which would act as both a liveness check and a
reset for no additional round-trip cost.
Please take a look and let me know what you think. I would like to
think this is something that is possible without submitting an RFC,
but of course if people feel that is necessary I'm able to go that
route.
Thanks!
[1] https://github.com/php/php-src/pull/21857
[2] https://github.com/php/php-src/issues/20225
Hi
Am 2026-04-27 20:09, schrieb Eric Norris:
Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think.
I agree that it is a reasonable expectation from users to use the latest
(or at least: a supported) version of third party software when they
want to use the latest PHP version. Especially since my understanding is
that in this instance, the communication would also not be broken
entirely, but users would just need to disable persistent connections,
no? This means if they want to upgrade PHP, without being able to
upgrade their MySQL version they would potentially need to give up some
performance optimization, but other than that it would work unchanged?
Somewhat relatedly, see:
https://github.com/php/php-src/pull/21159#issuecomment-4111691063. I
think it would be good to decide both cases at the same time, since they
are reasonably similar.
Best regards
Tim Düsterhus
Hi
Am 2026-04-27 20:09, schrieb Eric Norris:
Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think.I agree that it is a reasonable expectation from users to use the latest
(or at least: a supported) version of third party software when they
want to use the latest PHP version. Especially since my understanding is
that in this instance, the communication would also not be broken
entirely, but users would just need to disable persistent connections,
no? This means if they want to upgrade PHP, without being able to
upgrade their MySQL version they would potentially need to give up some
performance optimization, but other than that it would work unchanged?
That's a great point, and correct - users can still upgrade, they just
will need to give up persistent connections.
Somewhat relatedly, see:
https://github.com/php/php-src/pull/21159#issuecomment-4111691063. I
think it would be good to decide both cases at the same time, since they
are reasonably similar.
That could make sense, and how would you suggest we proceed to decide
the case? I'll admit that I'd be hesitant to need to resolve that via
an RFC, since if the RFC failed I'd need to potentially make another
RFC just for my change + some INI setting, and so it'd be quite some
time until I could get this merged. That's not to say we shouldn't do
it, I'm just noting my hesitation.
Hi
Am 2026-04-30 16:11, schrieb Eric Norris:
Somewhat relatedly, see:
https://github.com/php/php-src/pull/21159#issuecomment-4111691063. I
think it would be good to decide both cases at the same time, since
they
are reasonably similar.That could make sense, and how would you suggest we proceed to decide
the case? I'll admit that I'd be hesitant to need to resolve that via
an RFC, since if the RFC failed I'd need to potentially make another
RFC just for my change + some INI setting, and so it'd be quite some
time until I could get this merged. That's not to say we shouldn't do
it, I'm just noting my hesitation.
A single RFC with two primary votes to independently resolve each of the
two cases (at the same time) would work. Given the concerns and the
similarity between both, I don't think we can do without an RFC.
Best regards
Tim Düsterhus
A single RFC with two primary votes to independently resolve each of the
two cases (at the same time) would work. Given the concerns and the
similarity between both, I don't think we can do without an RFC.
Fair enough. I'd appreciate your collaboration on this RFC if you're
amenable! I've started a draft here:
https://wiki.php.net/rfc/min_supported_versions_php_8_6.
I have a few things to note:
- I wasn't sure how to approach the merger of the two topics. I
decided to model this like the various deprecation RFCs, in that we're
deciding on a slate of minimum supported software for PHP 8.6. - Ideally, if people objected to the MySQL minimum version for
persistent connections, I'd be able to include a vote that allowed for
an INI setting. - Related to that: I'm not sure how much detail to add about the
actual implementation I'd like for persistent connections. Is this a
vote for my specific implementation, or just the higher-level concept
of requiring a certain version of software in PHP 8.6? My goal is to
ship this, so needing to do two RFCs back-to-back would be annoying.
Feel free to respond privately if you'd like to take this off-list. Thanks!
Hi
Am 2026-05-03 16:14, schrieb Eric Norris:
- I wasn't sure how to approach the merger of the two topics. I
decided to model this like the various deprecation RFCs, in that we're
deciding on a slate of minimum supported software for PHP 8.6.
Yes, that makes sense to me.
- Ideally, if people objected to the MySQL minimum version for
persistent connections, I'd be able to include a vote that allowed for
an INI setting.
This would effectively be two competing RFCs and that could work with
our voting policy. One possible issue is that folks might be biased
against voting for the upgrade if there is the INI escape hatch. I
really don't like the extra maintenance effort (e.g. duplicate code
paths that no one is going to test) of the INI. I generally think an
opinionated RFC by a subject matter expert (i.e. you :-)) is stronger
than one that leaves every decision up to the voters.
- Related to that: I'm not sure how much detail to add about the
actual implementation I'd like for persistent connections. Is this a
vote for my specific implementation, or just the higher-level concept
of requiring a certain version of software in PHP 8.6? My goal is to
ship this, so needing to do two RFCs back-to-back would be annoying.
IMO it should be a vote for the increased minimum version with a good
argument as to why this increased minimum version is useful,
specifically “more predictable behavior for persistent connections,
because any per-connection state can cleanly be reset” and “support for
C11 in autotools, which already is the documented minimum in
https://github.com/php/php-src/blob/8d0777e88b8494807727fc57c148c2497976eff5/CODING_STANDARDS.md?plain=1#L12,
but folks will only notice if compilation fails halfway through”.
Best regards
Tim Düsterhus
This would effectively be two competing RFCs and that could work with
our voting policy. One possible issue is that folks might be biased
against voting for the upgrade if there is the INI escape hatch. I
really don't like the extra maintenance effort (e.g. duplicate code
paths that no one is going to test) of the INI. I generally think an
opinionated RFC by a subject matter expert (i.e. you :-)) is stronger
than one that leaves every decision up to the voters.
Fair enough! I'll see where the discussion goes and use that to inform
my decision, but stick with a single vote for now.
IMO it should be a vote for the increased minimum version with a good
argument as to why this increased minimum version is useful,
specifically “more predictable behavior for persistent connections,
because any per-connection state can cleanly be reset” and “support for
C11 in autotools, which already is the documented minimum in
https://github.com/php/php-src/blob/8d0777e88b8494807727fc57c148c2497976eff5/CODING_STANDARDS.md?plain=1#L12,
but folks will only notice if compilation fails halfway through”.
That makes sense to me. That said, I don't personally have anything
more to say about the autoconf change, other than "it sounds like a
good idea." I will need you or someone (Peter Kokot?) who is more
knowledgeable about autoconf and the build system to write that
section if we're going to make this a combined RFC.
Hi
Apologies for the late reply. It's been a busy May for me with
conferences and other important day job duties.
Am 2026-05-08 14:54, schrieb Eric Norris:
IMO it should be a vote for the increased minimum version with a good
argument as to why this increased minimum version is useful,
specifically “more predictable behavior for persistent connections,
because any per-connection state can cleanly be reset” and “support
for
C11 in autotools, which already is the documented minimum in
https://github.com/php/php-src/blob/8d0777e88b8494807727fc57c148c2497976eff5/CODING_STANDARDS.md?plain=1#L12,
but folks will only notice if compilation fails halfway through”.That makes sense to me. That said, I don't personally have anything
more to say about the autoconf change, other than "it sounds like a
good idea." I will need you or someone (Peter Kokot?) who is more
knowledgeable about autoconf and the build system to write that
section if we're going to make this a combined RFC.
Something like this should hopefully work:
The officially documented minimum version of the C standard that is
supported by PHP is C11 as of PHP
8.4.
This requirement is however not explicitly checked in a programmatic
fashion, which means that users trying to build PHP with an older
compiler that does not support the C11 standard might encounter
non-obvious build failures. The currently used minimum version of
autoconf, which is the tool used to generate the ./configure script
which is used for feature detection, is 2.68 and does not yet know
about C11, preventing it from reliably detecting the minimum
requirement and associated features.We propose increasing the minimum version of autoconf 2.71 from 2.69.
The updated version has official support for C11 and also allows to
simplify some of the existing autoconf definitions, simplifying
maintenance for the PHP Core team.autoconf is only required when building from git. The official PHP
release tarballs contain a pre-generated ./configure script that is
generated by the release managers, thus this change does not affect
users that build from the official releases. For users that build from
git, autoconf 2.71 was released in January 2021 and is available by
default in the current stable versions for all common Linux
distributions. This includes Debian 12+ (Bookworm), Ubuntu 22.04+
(jammy), RHEL 10, Fedora 38+, Alpine Linux 3.16+, OpenSuse Leap 16.
Best regards
Tim Düsterhus
Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think. Notably, if we were to
implement configuration for this we'd likely need to introduce yet
another INI variable; I have an impression that PHP maintainers are
somewhat skeptical of adding new INI settings.
I think it's ok to drop support of EOL versions. But I also think it's
possible to support both new and ancient mysql even without any runtime
options (ini setting, PDO constant et al). First try to send
COM_RESET_CONNECTION and if server return error, try COM_CHANGE_USER.
Result of this check may be cached for improved performance, but not
strictly necessary. This at least won't break anyone.
But if you are feel strongly about completely dropping COM_CHANGE_USER,
then some deprecation period should exist. Users should see at least
E_DEPRECATED errors in their logs before day X. I know about changelog
page and NEWS file, but among all the PHP programmers I know, no one reads
them.
Secondly, I'm curious what people think about implementing this in
both PDO andmysqlnd. In PDO, we can replace the liveness check
with this command, which would act as both a liveness check and a
reset for no additional round-trip cost.
It's ok to replace liveness check with reset, but I think you choose wrong
place for implementation. You changed the pdo_mysql_check_liveness
function and now it not just "liveness check", which leads to a discrepancy
with its name and also liveness functions from other PDO drivers. I'd
rather implement in on PDO level. Something like:
// pdo_dbh.c:420
/* is the connection still alive ? */
- if (pdbh->methods->check_liveness && FAILURE ==
(pdbh->methods->check_liveness)(pdbh)) {
+ if (!(pdbh->methods->reset && (pdbh->methods->reset)(pdbh)) &&
pdbh->methods->check_liveness && FAILURE ==
(pdbh->methods->check_liveness)(pdbh)) {
/* nope... need to kill it */
pdbh->refcount--;
zend_list_close(le);
pdbh = NULL;
}
See also the sluggish discussion about PDO:
https://externals.io/message/129740