clean preparedStatements cache after successful deallocate

[Thiht]

When trying to close a prepared statement on an aborted transaction, it's possible to clear the local prepared statement cache without actually deallocating the prepared statement in Postgres. So when trying to prepare the same statement a second time, this error occurs:

ERROR: prepared statement "stmt_xxx" already exists (SQLSTATE 42P05)

It's an issue we have in our tests but I wasn't able to isolate it as a runnable example (we use sqlx with the stdlib adapter, nested transactions, etc.) but the gist of it is:

• start a transaction
• prepare a statement stmt_xxx
• defer Close/Deallocate it
• abort the transaction (eg. SELECT 1/0)
• the deallocate fails in DB but clears the preparedStatements cache
  • ERROR: current transaction is aborted, commands ignored until end of transaction block (SQLSTATE 25P02)
• start a new transaction
• prepare the same statement stmt_xxx
  • ERROR: prepared statement "stmt_xxx" already exists (SQLSTATE 42P05)

[jackc]

I think this would fail to deallocate statements where the name was automatically generated from the SQL string.

[Thiht]

do you mean, like if you do something like this?

stmt, err := conn.Prepare(ctx, "select 1", "select 1")

?

in this case I'd say you're supposed to call Deallocate using stmt.Name, not the select 1 so I think it's not an issue, is it? or at least I don't think it changes the current behavior of Deallocate

[jackc]

@Thiht After looking again I think you are right -- it didn't change behavior with deallocating statements with auto-generated names.

However, when I looked closer I think there is a deeper issue. Prepared statements are not transactional. That is, a prepared statement persists even if the transaction it was created it is rolled back. However, theDEALLOCATE statement would fail if run in an aborted transaction. But the PostgreSQL protocol has a protocol level means (that is, not a SQL statement) to deallocate statements -- and it works even in an aborted transaction. I've changed pgx to use that means in #1797. Can you test that and see if it solves the issue you discovered?

It also implements the behavior you suggest here, but it should be now impossible for Deallocate to fail unless the connection is entirely broken.

[Thiht]

PostgreSQL protocol has a protocol level means (that is, not a SQL statement) to deallocate statements -- and it works even in an aborted transaction

Interesting stuff, seems like a good way to do in this case indeed.

I've changed pgx to use that means in #1797. Can you test that and see if it solves the issue you discovered?

Yep, I confirm it fixes the issue on my side.

I let you close this PR in favor of #1797 if everything's good for you