[php-src] Issue #23962: PDO: destroying a persistent PDO instance rolls back a transaction still in use by another instance

Issue: https://github.com/php/php-src/issues/23962 Author: BoyeMagnus ### Description ### Description With PDO::ATTR_PERSISTENT, several PDO instances with the same DSN share one connection. Destroying any one of them rolls back that connection's open transaction, even while another instance is still using it. The following code: ```php <?php $dsn = 'sqlite::memory:'; $a = new PDO($dsn, null, null, [PDO::ATTR_PERSISTENT => true]); $b = new PDO($dsn, null, null, [PDO::ATTR_PERSISTENT => true]); $b->beginTransaction(); var_dump($b->inTransaction()); unset($a); var_dump($b->inTransaction()); $b->commit(); ``` Resulted in this output: ``` bool(true) bool(false) Fatal error: Uncaught PDOException: There is no active transaction in /path/to/repro.php:13 ``` But I expected this output instead: ``` bool(true) bool(true) ``` The same happens with pdo_pgsql (DSN swapped for a Postgres one, same output), so it doesn't look driver-specific. ### Cause pdo_dbh_free_storage() in ext/pdo/pdo_dbh.c rolls back whenever pdo_is_in_transaction(dbh) is true, and only afterwards calls dbh_free(), which decrements the persistent handle's refcount and returns early while other instances still hold it: ```c if (dbh->driver_data && dbh->methods && dbh->methods->rollback && pdo_is_in_transaction(dbh)) { dbh->methods->rollback(dbh); dbh->in_txn = false; } ... dbh_free(dbh, 0); /* if (!free_persistent && (--dbh->refcount)) return; */ ``` So the rollback is applied to the shared connection regardless of whether another instance is still using it, and regardless of which instance began the transaction. I'd expect the rollback to happen only when the last instance releases the handle (or at request shutdown, so a transaction doesn't leak into the next request). ### Impact Code rarely creates two instances on purpose, but reconnect logic does it implicitly: it creates a new instance while the old one is still referenced, for example by an exception's trace arguments. We hit this in Laravel: after a pooled pgsql connection was closed by the server, Laravel's lost-connection retry reconnected and sent BEGIN, then the old instance was freed and rolled it back. The application's statements then ran in autocommit mode and commit() failed with the error above. So it silently loses atomicity rather than just throwing. ### PHP Version ```plain PHP 8.5.11 (cli) (built: Sep 22 2026 13:32:06) (NTS) Copyright (c) The PHP Group Built by Homebrew Zend Engine v4.5.11, Copyright (c) Zend Technologies with Zend OPcache v8.5.11, Copyright (c), by Zend Technologies ``` ### Operating System macOS 26 (also seen on Linux aarch64 in AWS Lambda)