On Wed, 1 Oct 2025 at 15:45, AllenJB <[email protected]> wrote: > As I understand it, at least in the case of MySQL, the state of > persistent connections is not managed by MySQL, but by the client (PHP). > This means that it's (at least theoretically) possible for a connection > to end up in an undesirable state, in which case there should be a way > to close it so it's not reused.
You are correct, and I can see this as a justification for adding a dangerous function; however, the circumstances you describe are very vague. What is this undesirable state, and how would someone be able to determine in code that the connection is in an undesirable state? More importantly, why would they need to close the connection when it happens instead of restoring it to a working state? The most common way I can imagine is if you acquire a lock on a table and then PHP script gets aborted due to an unhandled exception from something else (e.g. HTTP network request which failed due to outside reasons). But in that case, the persistent connection should be cleaned up by the custom error handler on the script's termination. Currently, there is no way to do that other than manually trying to release all locks/transactions/tables. A disconnect method would solve that, but so would a method to trigger COM_CHANGE_USER, which is still a worse solution than a simple function to reset the connection. If borked persistent connections are a real problem that needs solving, then I support adding a function to PDO to reset persistent connections. In MySQL, it would trigger COM_RESET_CONNECTION, and in other drivers an analogous solution would need to be found. This avoids the problem of having the PDO instance in a borked state. What I am trying to say is that there should be no need to ever close a persistent connection. If it ever gets messed up, it should be restored to the working state rather than being closed.
