`COM_RESET_CONNECTION` support in `mysqlnd`

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.

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.

I don't know that I feel strongly, but I also don't think it's worth
the complexity of a dual check and deprecation notice for (what I
imagine is) the small subset of users who want modern PHP but not
modern database software.

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.

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;
 }

Great catch, I'm somewhat embarrassed I didn't notice this myself. I
took your suggestion and updated the PR to include a new "reset
connection" hook for PDO that currently only mysqlnd implements. Thank
you!