Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128762
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 01 Oct 2025 20:07:55 +0200
To: "Kamil Tekiela" <tekiela246@gmail.com>, "Robert Wolf" <rposky@gmail.com>
Cc: "Claude Pache" <claude.pache@gmail.com>,
 "PHP internals" <internals@lists.php.net>
Message-ID: <df38d1c4-1ebd-4320-9b6c-1ddf725c426c@app.fastmail.com>
In-Reply-To: 
 <CAGBsUrftu_-XfQQhKpBM_YJp_VOJJ1FyWNi+1wqZ+77q4LQSiQ@mail.gmail.com>
References: 
 <CANdUeaZhn-8b2+LZDV3UnT1sx+BVFcz=m7neQHyv7huGega+_Q@mail.gmail.com>
 <CE73D727-9546-469F-A723-FE667CA4061D@gmail.com>
 <CANdUeaZ0u-BmdUuX9XD--H2CA0zys+J8j5Cem4YQd2Q555m9Vw@mail.gmail.com>
 <CAGBsUrftu_-XfQQhKpBM_YJp_VOJJ1FyWNi+1wqZ+77q4LQSiQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Discuss] Add PDO disconnect() and isConnected()
Content-Type: multipart/alternative;
 boundary=be16756372bd4010a764f57589cc91bc
From: rob@bottled.codes ("Rob Landers")

--be16756372bd4010a764f57589cc91bc
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 1, 2025, at 15:55, Kamil Tekiela wrote:
> On Wed, 1 Oct 2025 at 14:45, Robert Wolf <rposky@gmail.com> wrote:
> >
> > > I generally agree that there's little value to a disconnect() acti=
on; unset($pdo) is already sufficient.
> >
> > See the point again about persistent connections. The user has no me=
ans to disconnect in that case.
> >
> > > I recommend to use a name that deters users from using it in norma=
l operations, e.g. pdo->debug_manual_disconnect().
> >
> > Considering the above as well, a possible stance to take could be to=
 introduce it as persistent_disconnect(). We could then decide whether i=
t should function on "regular" connections as well.
>=20
> This sounds better, but I would argue that if it's a PERSISTENT
> connection, then it should be impossible for the user to close it. The
> idea is that the connection should remain open after being established
> and should only close when the server restarts. What scenario would
> necessitate the user to close a connection that should never close?

Off the top of my head (and it depends on the actual database on the oth=
er end of the pipe):
 1. After grant/role revocation, password rotation, or a switch from rea=
d/write replicas. Existing sessions usually keep there their privileges =
in a lot of databases. So, you could argue this is a security issue for =
long-lived applications.
 2. Perhaps you want to free any and all advisory locks?
 3. Sometimes the handle is alive, but the network connection is dead (t=
his is argued elsewhere though).
 4. I've had some fun bugs in the past with prepared statements crashing=
 a db server (putting it in maintenance mode and serving no traffic) bei=
ng shared between requests. If I could have slapped a "just close it unt=
il we figure out what is going on" statement in there, I would have.
 5. Replica promotion, primary failover, blue/green cutovers, firewall c=
hanges ... all these need new connections.
Right now, you have to jump through a number of hoops to do these types =
of operations.

=E2=80=94 Rob
--be16756372bd4010a764f57589cc91bc
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, Oct =
1, 2025, at 15:55, Kamil Tekiela wrote:</div><blockquote type=3D"cite" i=
d=3D"qt" style=3D""><div>On Wed, 1 Oct 2025 at 14:45, Robert Wolf &lt;<a=
 href=3D"mailto:rposky@gmail.com">rposky@gmail.com</a>&gt; wrote:</div><=
div>&gt;</div><div>&gt; &gt; I generally agree that there's little value=
 to a disconnect() action; unset($pdo) is already sufficient.</div><div>=
&gt;</div><div>&gt; See the point again about persistent connections. Th=
e user has no means to disconnect in that case.</div><div>&gt;</div><div=
>&gt; &gt; I recommend to use a name that deters users from using it in =
normal operations, e.g. pdo-&gt;debug_manual_disconnect().</div><div>&gt=
;</div><div>&gt; Considering the above as well, a possible stance to tak=
e could be to introduce it as persistent_disconnect(). We could then dec=
ide whether it should function on "regular" connections as well.</div><d=
iv><br></div><div>This sounds better, but I would argue that if it's a P=
ERSISTENT</div><div>connection, then it should be impossible for the use=
r to close it. The</div><div>idea is that the connection should remain o=
pen after being established</div><div>and should only close when the ser=
ver restarts. What scenario would</div><div>necessitate the user to clos=
e a connection that should never close?</div></blockquote><div><br></div=
><div>Off the top of my head (and it depends on the actual database on t=
he other end of the pipe):<br></div><ol><li>After grant/role revocation,=
 password rotation, or a switch from read/write replicas. Existing sessi=
ons usually keep there their privileges in a lot of databases. So, you c=
ould argue this is a security issue for long-lived applications.</li><li=
>Perhaps you want to free any and all advisory locks?</li><li>Sometimes =
the handle is alive, but the network connection is dead (this is argued =
elsewhere though).</li><li>I've had some fun bugs in the past with prepa=
red statements crashing a db server (putting it in maintenance mode and =
serving no traffic) being shared between requests. If I could have slapp=
ed a "just close it until we figure out what is going on" statement in t=
here, I would have.</li><li>Replica promotion, primary failover, blue/gr=
een cutovers, firewall changes ... all these need new connections.</li><=
/ol><div>Right now, you have to jump through a number of hoops to do the=
se types of operations.</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob</div></body></html>
--be16756372bd4010a764f57589cc91bc--