Hey all,
I hope you've been enjoying what appears to be the RFC "busy season".
I've got another RFC following up on an earlier thread about adding
COM_RESET_CONNECTION support to PDO and mysqlnd:
https://wiki.php.net/rfc/min_supported_versions_php_8_6
This proposes a minimum version requirement for autoconf when building
from source, and a minimum version requirement of MySQL 5.7.3 and
MariaDB 10.2.4 when using persistent connections.
- Original thread: https://news-web.php.net/php.internals/130704
- autoconf PR: https://github.com/php/php-src/pull/21159
- COM_RESET_CONNECTION PR: https://github.com/php/php-src/pull/21857
and original issue: https://github.com/php/php-src/issues/20225
(Tim, I've not added you as an author since I wasn't sure you'd be
cool with that, but if you'd like I would be more than happy to.)
Thank you,
Eric Norris
Hi
Am 2026-07-02 16:53, schrieb Eric Norris:
(Tim, I've not added you as an author since I wasn't sure you'd be
cool with that, but if you'd like I would be more than happy to.)
I'm okay with that.
And with regard to the RFC itself: Leaving the “Open Issues” and “Future
Scope” sections empty looks weird. I suggest to either remove them
completely or insert an explicit “None” or so. The same is true for the
SAPI impact. The changelog could just be an "- 2026-07-02: Initial
version" and then "- 2026-07-02: Clarify impact" (see below).
The “References” section should ideally include links to the Pre-RFC
discussion thread and must include a link to this discussion. For your
convenience: https://news-web.php.net/php.internals/131707 +
https://news-web.php.net/php.internals/130704).
An “ecosystem impact” of “None” is also almost always wrong. I would
mention the following (perhaps with a little nicer phrasing).
- For COM_RESET_CONNECTION: The proper reset on persistent connections
has the (positive) impact that the behavior of persistent connections
will be more predictable. Of course if folks rely on some connection
state carrying over across requests, they might see a breaking change. - Users that want to use the newest PHP version will be required to also
run newer versions (released in the last 5 years) of other software.
Best regards
Tim Düsterhus
Hi
Am 2026-07-02 16:53, schrieb Eric Norris:
(Tim, I've not added you as an author since I wasn't sure you'd be
cool with that, but if you'd like I would be more than happy to.)I'm okay with that.
And with regard to the RFC itself: Leaving the “Open Issues” and “Future
Scope” sections empty looks weird. I suggest to either remove them
completely or insert an explicit “None” or so. The same is true for the
SAPI impact. The changelog could just be an "- 2026-07-02: Initial
version" and then "- 2026-07-02: Clarify impact" (see below).The “References” section should ideally include links to the Pre-RFC
discussion thread and must include a link to this discussion. For your
convenience: https://news-web.php.net/php.internals/131707 +
https://news-web.php.net/php.internals/130704).An “ecosystem impact” of “None” is also almost always wrong. I would
mention the following (perhaps with a little nicer phrasing).
- For COM_RESET_CONNECTION: The proper reset on persistent connections
has the (positive) impact that the behavior of persistent connections
will be more predictable. Of course if folks rely on some connection
state carrying over across requests, they might see a breaking change.- Users that want to use the newest PHP version will be required to also
run newer versions (released in the last 5 years) of other software.Best regards
Tim Düsterhus
Thank you, I've both added you as an author and included your
suggested changes, with slight edits.
Hi
Am 2026-07-02 17:48, schrieb Eric Norris:
Thank you, I've both added you as an author and included your
suggested changes, with slight edits.
Thank you. No further remarks from my side.
Best regards
Tim Düsterhus
Users that are on MySQL or MariaDB databases from before this feature was implemented may upgrade to PHP 8.6, but would not be able to use persistent connections. This means that their software could continue to work, but they might lose a performance optimization.
Please clarify this.
Users on older mysql will hit connection error immediately after
upgrading to 8.6. So saying "their software could continue to work" is
misleading. Their PHP code must be modified before upgrading - turning
PDO::ATTR_PERSISTENT to false or removing it entirely. And only after
that it would continue to work.
Users that are on MySQL or MariaDB databases from before this feature was implemented may upgrade to PHP 8.6, but would not be able to use persistent connections. This means that their software could continue to work, but they might lose a performance optimization.
Please clarify this.
Users on older mysql will hit connection error immediately after
upgrading to 8.6. So saying "their software could continue to work" is
misleading. Their PHP code must be modified before upgrading - turning
PDO::ATTR_PERSISTENT to false or removing it entirely. And only after
that it would continue to work.
Is this true? Having looked at the persistent connection code, I
believe it would silently handle the error by simply discarding the
connection and creating a new one. Thus, "their software could
continue to work, but they might lose a performance optimization."
Is this true?
It's not true. Sorry about that. Script didn't crash.
But something worse happened.
I took sources from
https://github.com/ericnorris/php-src/archive/refs/heads/feat-mysqlnd-com-reset-connection.zip
Configured them with --enable-mysqlnd --enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --enable-pdo --with-pdo-mysql=mysqlnd
Up mysql 5.5.61.
Started php-fpm with pm = static and pm.max_children = 1.
Ran this script:
<?php
$pdo = new PDO('mysql:host=172.17.0.1', 'root', '',
[PDO::ATTR_PERSISTENT => true]);
$q = $pdo->query('SHOW PROCESSLIST');
$rows = 0;
while ($f = $q->fetch(PDO::FETCH_ASSOC)) {
$rows++;
}
echo $rows . PHP_EOL;
On the first execution script echoes 1. On the second - 2. Each
execution increments the counter by one. When I restart the php-fpm
process, the counter restarts again from 1. There is connection leak
here!
When I removed PDO::ATTR_PERSISTENT, the counter stop increasing.
When I switched to mysql 8, counter was always 1 (both with and
without persistent connections).
Is this true?
It's not true. Sorry about that. Script didn't crash.
But something worse happened.
I took sources from
https://github.com/ericnorris/php-src/archive/refs/heads/feat-mysqlnd-com-reset-connection.zip
Configured them with--enable-mysqlnd --enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --enable-pdo --with-pdo-mysql=mysqlnd
Up mysql 5.5.61.
Started php-fpm withpm = staticandpm.max_children = 1.
Ran this script:<?php $pdo = new PDO('mysql:host=172.17.0.1', 'root', '', [PDO::ATTR_PERSISTENT => true]); $q = $pdo->query('SHOW PROCESSLIST'); $rows = 0; while ($f = $q->fetch(PDO::FETCH_ASSOC)) { $rows++; } echo $rows . PHP_EOL;On the first execution script echoes 1. On the second - 2. Each
execution increments the counter by one. When I restart the php-fpm
process, the counter restarts again from 1. There is connection leak
here!When I removed
PDO::ATTR_PERSISTENT, the counter stop increasing.
When I switched to mysql 8, counter was always 1 (both with and
without persistent connections).
Thank you for identifying a connection leak; I have identified the
cause and I'm considering how to address it. That said, I don't
believe this is inherent to the RFC, instead I would consider this a
bug in my implementation.
Hey all,
I hope you've been enjoying what appears to be the RFC "busy season".
I've got another RFC following up on an earlier thread about adding
COM_RESET_CONNECTION support to PDO and mysqlnd:https://wiki.php.net/rfc/min_supported_versions_php_8_6
This proposes a minimum version requirement for autoconf when building
from source, and a minimum version requirement of MySQL 5.7.3 and
MariaDB 10.2.4 when using persistent connections.
- Original thread: https://news-web.php.net/php.internals/130704
- autoconf PR: https://github.com/php/php-src/pull/21159
- COM_RESET_CONNECTION PR: https://github.com/php/php-src/pull/21857
and original issue: https://github.com/php/php-src/issues/20225(Tim, I've not added you as an author since I wasn't sure you'd be
cool with that, but if you'd like I would be more than happy to.)Thank you,
Eric Norris
I know there are a lot of other RFCs going around, so I'm sending this
intent to vote message at the earliest possible time as permitted by
the RFC policy. I intend to open a vote in 7 days on July 16th,
exactly 14 days after my initial message (and the last changes to the
RFC). Please take a look if you haven't already.
Thanks!