Date: Wed, 3 Jun 2026 16:17:31 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
	pgsql-hackers@postgresql.org
Subject: Re: alert clients when prepared statements are deallocated
Message-ID: <aiCZ60MNyTQ8_4BE@nathan>
References: <ahm_4eOKkkKJ3Gds@nathan>
 <1689313.1780074543@sss.pgh.pa.us>
 <ahna7lre-xAn7DIS@nathan>
 <ah9VKGwwlgqF-hi7@nathan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ah9VKGwwlgqF-hi7@nathan>
Archived-At: <https://www.postgresql.org/message-id/aiCZ60MNyTQ8_4BE%40nathan>
Precedence: bulk

On Tue, Jun 02, 2026 at 05:11:52PM -0500, Nathan Bossart wrote:
> * I'm a little worried about race conditions involving a client trying to
> use a statement while a deallocation message is in flight, but I haven't
> identified anything concrete so far.  This is something I'd like to
> investigate some more, though.

Hm.  So there's actually a pretty obvious problem here.  Say a user
executes something like PQsendQuery(conn, "DISCARD ALL") and then tries to
execute an lo_* function (modified to use prepared statements) prior to
consuming the result.  In that case, the callback won't be called in time
and the LO function will fail.

My first instinct is that this is a showstopper for $subject, but perhaps
it is a rare enough scenario that we could live with documenting it.  My
suspicion is that it's uncommon for folks to asynchronously deallocate all
prepared statements, and I don't know why you'd use PQsendClosePrepared()
on statements named libpq_internal_*.  Nevertheless, this seems like a
rather large hole.

I think this calls into question whether moving the libpq interface to
prepared statements makes sense.  If we can't do that, I think we're pretty
much forced to keep the fast-path around forever or to accept a larger
performance hit.  In any case, I find it a little strange that there's not
a great way to use prepared statements internally in libpq, which is why
I'm chasing this a little more than perhaps I should.

-- 
nathan