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

Поиск
Список
Период
Сортировка
От Dominique Devienne
Тема Re: prepared statement "cu1" already exists (but it does not)
Дата
Msg-id CAFCRh--GRPHBhdgrnQOMRves3hKr==S90Mkq7RmnRgjChX8gVw@mail.gmail.com
обсуждение исходный текст
Ответ на [MASSMAIL]prepared statement "cu1" already exists (but it does not)  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
Список 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 по дате отправления:

Предыдущее
От: Sebastien Flaesch
Дата:
Сообщение: Re: prepared statement "cu1" already exists (but it does not)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: prepared statement "cu1" already exists (but it does not)