agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: alert clients when prepared statements are deallocated
Date: Fri, 29 May 2026 13:29:02 -0500
Message-ID: <ahna7lre-xAn7DIS@nathan> (raw)
In-Reply-To: <1689313.1780074543@sss.pgh.pa.us>
References: <ahm_4eOKkkKJ3Gds@nathan>
<1689313.1780074543@sss.pgh.pa.us>
On Fri, May 29, 2026 at 01:09:03PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> 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.
>
> Of course the first question about that is "why doesn't the client
> know that already ... didn't it issue the deallocate itself?".
> The core answer to that question is that there might be multiple
> levels of client code involved, so that while some level of the client
> stack probably knows it in some way, other levels might have created
> prepared statements and not be aware that they're gone.
Right.
> Therefore, having the server report this is only a partial answer
> to the problem: it will only directly provide a fix to the bottom
> client code level. To go further you'd need some inside-the-client
> mechanism for propagating the notification up the client stack.
> We can't really create that in general, but we can at least make
> libpq be a responsible citizen in that chain. In short, a proposed
> fix for this must also provide a way for the calling application to
> hear about these reports, and a way for it to fall back if they're
> not available.
This is the intent of the callback mechanism. In short, a libpq user could
register a callback that runs as soon as a deallocation notification is
received. We could also add a default callback that stores a list of
deallocated prepared statements (or a subset that a caller has indicated
interest in). Callers could then call libpq-provided functions to retrieve
and reset that list. My hunch is that might be more convenient for
projects that use language bindings.
--
nathan
view thread (13+ messages) latest in thread
Message-ID: <ahna7lre-xAn7DIS@nathan>
Permalink: ../ahna7lre-xAn7DIS@nathan/
Also on: postgresql.org/message-id/ahna7lre-xAn7DIS@nathan
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, tgl@sss.pgh.pa.us, jacob.champion@enterprisedb.com
Subject: Re: alert clients when prepared statements are deallocated
In-Reply-To: <ahna7lre-xAn7DIS@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox