Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129863 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 3C9591A00BC for ; Thu, 22 Jan 2026 16:31:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1769099474; bh=6HS5IsWzoYYCjNyAoWRw00V6BtPka+gBXB5QErryauc=; h=From:Subject:Date:To:From; b=hF/rlSIOweecSbzEQjt8eaOmtxps5Ot6f6U8EPNHh/6Uh3I8cTqCVy540XuCt4PI8 Ftls6z6FmsBGBgVzJ6BI9K16UttTYxF82/TNrfhNDwWWCpP0yuJe00a28Sm9sd+ywm OXGZxgtRCNlgv/5tqL6r2bcpa/2m3WMl9ShUy9qmsj2zZU17+GnSKAFtuG7ELoSQgA /b0B5OrLpo5+1/JB2eMTToVybW6s4QHwUDGUeU1R8JroSG/4rNa84qOMdp8WUJBb1N b0tdqmsdje942J2qtJXZyc+qAysh3Wo0uUcRPazROGX8Psju8DVGsBYK/xS/VlMm2n 0sCeETuFrRuTQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9EC78180AE7 for ; Thu, 22 Jan 2026 16:31:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DMARC_MISSING, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from supercat.cmpct.info (supercat.cmpct.info [71.19.146.230]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 22 Jan 2026 16:31:12 +0000 (UTC) Received: from smtpclient.apple (fctnnbsc38w-142-134-101-31.dhcp-dynamic.fibreop.nb.bellaliant.net [142.134.101.31]) by supercat.cmpct.info (Postfix) with ESMTPSA id 1580F415F4 for ; Thu, 22 Jan 2026 16:31:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: [PHP-DEV] Reconnecting persistent connections in PDO Message-ID: <7ED95681-14AD-4F57-B97B-DBC1B56D3529@cmpct.info> Date: Thu, 22 Jan 2026 12:30:49 -0400 To: PHP internals X-Mailer: Apple Mail (2.3864.300.41.1.7) From: calvin@cmpct.info (Calvin Buckley) Hi internals, There's been some discussion over how to deal with persistent connections in PDO. I know this is a common problem users deal with; sometimes the connection has been put into a bad state (i.e. search paths or some other connection-level state being set by user code), or the PDO liveness check may not be perfect for all drivers (i.e. for PDO_ODBC, it depends heavily on the connection dead attribute implementation in the driver). I've at least acknowledged this as a general problem for persistent resources/objects before (GH-15749). I've seen users cope with bad persistent connections by killing the PHP process running into it, which is obviously not ideal. There's been some proposals to fix this; mostly by adding a close method to PDO (GH-19933/GH-19214), but this complicates PDO by making closed connection objects a thing. I have a draft PR (GH-21007) that simply provides an attribute for throwing away the current persistent connection and getting a new one; this allows userland code to implement their own reconnect and recovery behaviours. However, I'm still not very sure it's the best approach, as said recovery code is awkward code that users need to implement for themselves. I've thought about some alternatives (i.e. allow hooking liveness checks to supplement with user code), but I haven't implemented those. I'd appreciate some thoughts or proposals on the manner, since this is a papercut that I've seen users deal with. Regards, Calvin GH issues/PRs mentioned: https://github.com/php/php-src/pull/15749 https://github.com/php/php-src/pull/19214 https://github.com/php/php-src/pull/19933 https://github.com/php/php-src/pull/21007