Date: Fri, 29 May 2026 11:33:37 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org
Subject: alert clients when prepared statements are deallocated
Message-ID: <ahm_4eOKkkKJ3Gds@nathan>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="tbByXeXYMjI7URMk"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/ahm_4eOKkkKJ3Gds%40nathan>
Precedence: bulk


--tbByXeXYMjI7URMk
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

(Moving to a new thread since this seems like an independent feature.
Original discussion can be found here:
https://postgr.es/m/ahXE28klgxIJXBLq%40nathan)

When trying to take our own advice and teach the frontend LO interface to
use prepared statements instead of PQfn(), I discovered a couple of
problems.  The biggest problem is that clients aren't alerted when a
prepared statement is deallocated with DISCARD or DEALLOCATE.  Since this
seems like a general problem that affects more than just libpq's LO
functions, I'm seeing whether it makes sense to add some sort of
notification mechanism so that clients can re-prepare as needed.  Some
initial discussion about the work-in-progress patch (which I've attached
again here) follows:

On Fri, May 29, 2026 at 11:10:58AM -0500, Nathan Bossart wrote:
> On Fri, May 29, 2026 at 08:43:07AM -0700, Jacob Champion wrote:
>> On Fri, May 29, 2026 at 8:14 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>>> Here is a work-in-progress patch set that goes this direction.
>> 
>> At a high level, I think advertising support for a single new message
>> needs to be done in a protocol extension rather than a minor version
>> bump.
> 
> WFM
> 
>>> This
>>> introduces a callback mechanism in libpq that is used to handle statement
>>> deallocation notifications.  Older servers/clients fall back to
>>> PQexecParams(), which is slower, but the alternative is to leave PQnfn()
>>> and related code around indefinitely.
>> 
>> IMO there's no hurry in getting rid of that path. If we decide to go
>> this direction, a fallback to PQnfn() seems like it'd fine for a few
>> releases; we could eventually swap to a PQexecParams() fallback and
>> get rid of the extra code once the older servers have aged out.
> 
> That's fine with me, too.
> 
>>> I'm wondering whether this new message type is general enough.  For
>>> example, perhaps we could make an extensible message type for tracking
>>> various things.  And I want to ensure this is useful for other clients,
>>> too.
>> 
>> If it's just a general notification message, what does negotiating
>> "support" mean? Is best-effort notification okay, if the client has no
>> idea what a future message type means, or if the server doesn't send
>> the specific type of message the client is hoping for?
> 
> That's what I had in mind.  But if we don't have anything specific in mind
> that this mechanism could be extended to support, maybe we shouldn't
> bother.  Especially if we can just add protocol extensions as necessary.
> 
>> (In general, I'm kind of down on the "notify the client that X
>> happened" method of working around architectural issues. Maybe that's
>> what we need to move this specific part forward, but it doesn't feel
>> like a long-term solution and I don't know that we need to genericize
>> it without a solid set of use cases.)
> 
> I'm certainly open to other ideas, but I'm afraid this is the best I've
> come up with in my admittedly limited time thinking about the problem.

-- 
nathan

--tbByXeXYMjI7URMk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v2-0001-tell-client-when-prep-stmts-are-deallocated.patch