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.