Jelte Fennema-Nio

> I also don't see how a Close message can replace DEALLOCATE. Afaict `Close` is the protocol level equivalent of DEALLOCATE (except it does not support ALL). From the Postgres...

After trying to quickly implement a POC of this myself. I realized it wasn't as easy as I thought because libpq doesn't actually expose an interface to send a `Close`...

It's merged now (for PG17): https://github.com/postgres/postgres/commit/28b5726561841556dc3e00ffe26b01a8107ee654 So can this issue be re-opened?

Can this issue be re-opened?

Not yet... Had too many other things to do so far

> One option could be to add a config knob to just not call DEALLOCATE: https://www.crunchydata.com/blog/prepared-statements-in-transaction-mode-for-pgbouncer#caveat-two-beware-of-deallocation You can do this by setting prepared_max to None or float('infinity') I think: https://www.psycopg.org/psycopg3/docs/api/connections.html#psycopg.Connection.prepared_max

It wasn't really on my radar at this point. But DEALLOCATE ALL is now supported by PgBouncer (plain DEALLOCATE still not)

> * from which PgBouncer release is protocol-level deallocation (via `PQsendClosePrepared`) supported? 1.21.0 > * from which PgBouncer release is DEALLOCATE ALL supported? 1.22.0

> That disables preprared statements. I'd like to be able to use them :) Setting `prepared_max` to `float('infinity')` enables prepared statements, but effectively disables the `DEALLOCTE` logic.

> but I imagine I can run a psycopg build that uses libpq 17 right now against postgres 16 and it should (generally) work? Yes that should work fine