Everything

php

`COM_RESET_CONNECTION` support in `mysqlnd`

php.internals

Eric Norris

127 days ago

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

Tim Düsterhus

124 days ago

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

Eric Norris

124 days ago

On Thu, Apr 30, 2026 at 3:49 AM Tim Düsterhus <tim@bastelstu.be> wrote:

>
> 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.

Tim Düsterhus

121 days ago

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

Eric Norris

121 days ago

On Sun, May 3, 2026 at 8:01 AM Tim Düsterhus <tim@bastelstu.be> wrote:

>
> 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!

Tim Düsterhus

116 days ago

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

Eric Norris

116 days ago

> 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.

Tim Düsterhus

91 days ago

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](https://github.com/php/php-src/commit/631bab42ddef8e90964558fe8b1df80157e12986).
> 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

Eric Norris

61 days ago

On Tue, Jun 2, 2026 at 9:26 AM Tim Düsterhus <tim@bastelstu.be> wrote:

>
> 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](https://github.com/php/php-src/commit/631bab42ddef8e90964558fe8b1df80157e12986).
> > 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

Thank you, I've added that verbatim to the RFC draft and published it
for discussion.

Unnamed Person

105 days ago

> 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 *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:

```c
// 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

Eric Norris

61 days ago

On Tue, May 19, 2026 at 6:55 AM <go.al.ni@gmail.com> wrote:

>
> > 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:
>
> ```c
> // 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!