Not seeing too much in the forums about this but wondering if it is possible to run Temporal self-hosted with pg bouncer in front of postgres.
Seem to be running into errors like
2024-07-24T15:26:47.810Z [34mINFO[0m UpdateSchemeTask started {"config": {"DBName":"","TargetVersion":"","SchemaDir":"/etc/temporal/schema/postgresql/v96/temporal/versioned","IsDryRun":false}, "logging-call-at": "updatetask.go:97"} 2024-07-24T15:26:47.814Z [31mERROR[0m Unable to update SQL schema. {"error": "error reading current schema version:pq: bind message supplies 1 parameters, but prepared statement \"\" requires 2", "logging-call-at": "handler.go:78"}
as part of startup of frontend service. And other errors like
{"level":"error","ts":"2024-07-24T15:26:49.927Z","msg":"Operation failed with internal error.","error":"GetClusterMembers operation failed. Error: pq: bind message supplies 4 parameters, but prepared statement \"\" requires 2","metric-scope":87,"logging-call-at":"persistenceMetricClients.go:1579","stacktrace":"go.temporal.io/server/common/log.(*zapLogger).Error\n\t/home/builder/temporal/common/log/zap_logger.go:143\ngo.temporal.io/server/common/persistence.
Reviewing Postgres, pq, pgbouncer, and prepared statements. SQL_CONNECT_ATTRIBUTES did seem to help get through start up script but not the connection attributes (binary_parameters part)
changing to session pooling seems to fix as well, just wondering if Temporal would expect or require transaction or statement instead.
Pool mode specifies when a server connection can be reused by other clients.
session = Server is released back to pool after client disconnects. Default.
transaction = Server is released back to pool after transaction finishes.
statement = Server is released back to pool after query finishes. Transactions spanning multiple statements are disallowed in this mode.
https://www.pgbouncer.org/config.html