Re: [PHP-DEV] [RFC] [Discussion] Minimum supported versions for PHP 8.6

Mailing Lists php.internals
1

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.

2

On Thu, Jul 2, 2026 at 11:42 AM <go.al.ni@gmail.com> wrote:

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

Source: feat(mysqlnd): send COM_RESET_CONNECTION in restart_psession by ericnorris · Pull Request #21857 · php/php-src · GitHub

3

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

4

On Fri, Jul 3, 2026 at 7:32 AM <go.al.ni@gmail.com> wrote:

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

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.