0

I set max_prepared_statements = 1 in PgBouncer and attempted to create multiple prepared statements within a single transaction.

Expected Behavior:

PgBouncer should either prevent more than one prepared statement from being created, OR It should immediately delete the prepared statement after committing the transaction.

Actual Behavior:

PgBouncer allowed multiple prepared statements to be created and executed, even with max_prepared_statements set to 1.

Has anyone else encountered this issue? Is this the expected behavior, or am I missing a configuration setting?

PGBouncer: 1.21v PostgreSQL: 14.3v Pool mode: Transaction

Improve this question
3
  • Did you read Config: max_prepared_statements. In particular: Note: This tracking and rewriting of prepared statement commands does not work for SQL-level prepared statement commands, so PREPARE, EXECUTE and DEALLOCATE are forwarded straight to Postgres. Commented Feb 5 at 15:57
  • @AdrianKlaver I tried using JDBC connections but I'm still encountering the issue. Also, isn't a prepared statement created in one server connection inaccessible from another? For example, if the client uses server connection 1 to create a prepared statement, then disconnects and reconnects to server connection 2, will the prepared statement still exist? Commented Feb 6 at 8:04
  • 1) Read max_prepared_statements section at the link I posted, it goes into detail how pgbouncer accounts for prepared statements. 2) JDBC is just a driver, it does not say anything about how you are using prepared statements. 3) Look at the Postgres logs and see what is actually hitting the database. That with the information in 1) above should help you track down the issue. Commented Feb 6 at 16:39
Load 4 more related questions Show fewer related questions

0

Reset to default

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.