Add (and test) explicit support for PgBouncer

[mehcode]

Notable differences

• Prepared statements are invalid after a SYNC (so they can be used but may not be cached).

• Apparently does not support the startup parameter IntervalStyle. That may need to be deferred to a SET after connect.

[abonander]

How would PgConnection differentiate? Maybe a query parameter? ?pgbouncer=1 or something.

[mehcode]

@abonander My hope is we can identify that it's PgBouncer on start-up. If not we'll need to tinker and provide configuration for people to use. Perhaps a way to disable the prepared cache in the database url.

[Firaenix]

Any news on this? I would love to be able to use pgbouncer for my SQLX apps

[abonander]

We'd gladly accept a pull request that improves compatibility, but otherwise it's not currently a priority.

[mehcode]

You should be able to get support by turning off the prepared statement cache. Set the cache capacity to 0. See https://docs.rs/sqlx/0.5.5/sqlx/postgres/struct.PgConnectOptions.html#method.statement_cache_capacity

I haven't tried it but from the OP of this issue, it sounds like this should work.

[TuhinNair]

I can confirm that it does indeed work with the cache capacity set to 0.

Specifically, using PgBouncer's transaction pooling mode and statement cache capacity at 0, I was able to use sqlx with AWS Lambda to begin and commit transactions.

[crepererum]

I don't think setting the cache capacity to 0 works in all cases. If you run queries w/o any transaction and the cache size is 0, SQLx will still prepare the statement if the query has any arguments:

sqlx/sqlx-core/src/postgres/connection/executor.rs

Lines 209 to 214 in 32f1273

	let format = if let Some(mut arguments) = arguments {
	// prepare the statement if this our first time executing it
	// always return the statement ID here
	let (statement, metadata_) = self
	.get_or_prepare(query, &arguments.types, persistent, metadata_opt)
	.await?;

sqlx/sqlx-core/src/postgres/connection/executor.rs

Lines 177 to 179 in dd27aa0

	let statement = prepare(self, sql, parameters, metadata).await?;
	if store_to_cache && self.cache_statement.is_enabled() {

Since pgbouncer doesn't keep the "prepare" step and the execution together, this will lead to confusing error messages where prepared statements cannot be found.

I'm wondering if there is a way to pass arguments to a query w/o relying on "prepare statement" (and w/o having the user to do manual but safe string/parameter escaping).

[abonander]

I don't really think that's something that SQLx should tackle. I think that could be built as a generic SQL interpolation library.

If you have access to PgBouncer's config, it looks like you can set the pooling mode to Session which should make everything work as expected. Kinda defeats the point of PgBouncer, I guess, but it would work.

[uthng]

Hi,

I got the same issue with the error prepared statement sqlx_s_1 already exists while doing with pgbouncer. Setting capacity to 0 and persistent at query level to false did not help. I finally did a workaround with DEALLOCATE all; before each query execution.

[abonander]

@uthng more discussion here: #1740 (comment)