Re: prepared statement "cu1" already exists (but it does not) - Mailing list pgsql-general

From Dominique Devienne
Subject Re: prepared statement "cu1" already exists (but it does not)
Date
Msg-id CAFCRh--GRPHBhdgrnQOMRves3hKr==S90Mkq7RmnRgjChX8gVw@mail.gmail.com
Whole thread Raw
In response to [MASSMAIL]prepared statement "cu1" already exists (but it does not)  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
List pgsql-general
On Mon, Apr 8, 2024 at 5:31 PM Sebastien Flaesch <sebastien.flaesch@4js.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

pgsql-general by date:

Previous
From: Sebastien Flaesch
Date:
Subject: Re: prepared statement "cu1" already exists (but it does not)
Next
From: Tom Lane
Date:
Subject: Re: prepared statement "cu1" already exists (but it does not)