Re: prepared statement "cu1" already exists (but it does not)

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: prepared statement "cu1" already exists (but it does not)
Date: 2024-04-08 16:40:07
Message-ID: CAFCRh--GRPHBhdgrnQOMRves3hKr==S90Mkq7RmnRgjChX8gVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Apr 8, 2024 at 5:31 PM Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com>
wrote:

> I understand when this can happen, but in fact I do de-allocate prepared
> statements when I should.
>

We've run into similar issues. We're in C++, and with RAII deallocate
resources (Prepared Statements, Cursors) in Dtors.
But as you saw, when a TX is KO, any Dtor trying to release resources via
libpq will fail. So what I do it record those
resources (stmt and cursor names basically) on the Connection (in our
wrapper), and will release them at the first opportunity,
once the TX has rolled back for example. FWIW.

OTOH, we tend not to reuse names, generating random ones, since when using
our wrappers, the name is an impl details basically.
We also tend to prepare outside transactions, so can't answer your question
on whether prepared statements within TX are "scoped" or not. --DD

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2024-04-08 17:36:51 Re: prepared statement "cu1" already exists (but it does not)
Previous Message Sebastien Flaesch 2024-04-08 16:25:13 Re: prepared statement "cu1" already exists (but it does not)