Thanks all for your help.
I have discovered another fact: When surrounding the execution of the failing
INSERT with a savepoint + rollback to savepoint, the problem disappears: The
DEALLOCATE commands do then succeed.
See attached trace...
Seb
From: Tom Lane
Sebastien Flaesch writes:
> I understand that the whole TX is aborted with PostgreSQL, and probably the
> deallocate is useless since stmt was prepared inside the TX?
As you can quickly discover with some manual experimentation,
both PREPARE and DEALLOCATE are nontransactional, in the sense
On Mon, Apr 8, 2024 at 5:31 PM Sebastien Flaesch
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
Here a first PQtrace() file... assuming it can help.
Seb
From: Sebastien Flaesch
Sent: Monday, April 8, 2024 5:31 PM
To: pgsql-general
Cc: Sebastien Flaesch
Subject: prepared statement "cu1" already exists (but it does not)
Hello,
In a specific case, I get the
Hello,
We are currently using a shared PostgreSQL cluster (version 11.18) that
supports over ten databases. To alleviate the load on this cluster, we've
decided to migrate certain databases to dedicated clusters using the native
logical replication feature. This approach has been successfully
Hello,
In a specific case, I get the error
prepared statement "cu1" already exists
I understand when this can happen, but in fact I do de-allocate prepared
statements when I should.
I am investigating on this for several hours now, I thought I could share my
problem to see if this ring a
On 4/8/24 07:24, mark bradley wrote:
While installing PostgreSQL I am getting this error message during the
PEM server portion. Do I need the PEM server? If so, what is the solution?
PEM Server is an EDB product:
https://www.enterprisedb.com/docs/pem/latest/managing_pem_server/
You
On Mon, Apr 8, 2024 at 10:08 AM Josh Triplett wrote:
> - Is there a way to tell postgresql "this column contains cryptographic
> hashes, so you can do hash joins using any subset of the bits,
> without having to hash them again"? If not, should there be?
>
No, and no. (if I understand your
While installing PostgreSQL I am getting this error message during the PEM
server portion. Do I need the PEM server? If so, what is the solution?
Thanks!
[cid:b414e51e-598a-44bf-951a-ce754c0fa77d]
I'm planning to store cryptographic hashes (BLAKE3) in a column of a
postgresql table. I'm going to be doing a large number of operations of
roughly this form:
- Receive a large number of hashes via a web API call.
- Check which hashes aren't already in the database.
- Send back a bitmap to the
On Mon, Apr 8, 2024 at 9:41 AM David G. Johnston
wrote:
> On Monday, April 8, 2024, Ron Johnson wrote:
>
>> Four times, the word "referential_action" is used on this page, but it's
>> never mentioned what the possible referential actions are.
>>
>> Am I missing something?
>>
>>
On Monday, April 8, 2024, Ron Johnson wrote:
> Four times, the word "referential_action" is used on this page, but it's
> never mentioned what the possible referential actions are.
>
> Am I missing something?
>
> https://www.postgresql.org/docs/14/sql-altertable.html
>
Much of the details
> On Apr 8, 2024, at 06:37, Ron Johnson wrote:
>
> Four times, the word "referential_action" is used on this page, but it's
> never mentioned what the possible referential actions are.
They're defined in CREATE TABLE:
https://www.postgresql.org/docs/14/sql-createtable.html
Four times, the word "referential_action" is used on this page, but it's
never mentioned what the possible referential actions are.
Am I missing something?
https://www.postgresql.org/docs/14/sql-altertable.html
[ CONSTRAINT constraint_name ]
[snip]
PRIMARY KEY index_parameters |
REFERENCES
14 matches
Mail list logo
