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