Several levels of brutality when rotating connections:
This mode breaks a few session-based features of PostgreSQL. You can use it only when the application cooperates by not using features that break. See the table below for incompatible features.
Low memory requirements (2 kB per connection by default). This is because PgBouncer does not need to see full packets at once.
It is not tied to one backend server. The destination databases can reside on different hosts.
Supports online reconfiguration for most settings.
Supports online restart/upgrade without dropping client connections.
The following table list various PostgreSQL features and whether they are compatible with PgBouncer pooling modes. Note that “transaction” pooling breaks client expectations of the server by design and can be used only if the application cooperates by not using non-working features.
Feature | Session pooling | Transaction pooling |
---|---|---|
Startup parameters 1 | Yes | Yes |
SET/RESET | Yes | Never |
LISTEN | Yes | Never |
NOTIFY | Yes | Yes |
WITHOUT HOLD CURSOR | Yes | Yes |
WITH HOLD CURSOR | Yes | Never |
Protocol-level prepared plans | Yes | Yes 2 |
PREPARE / DEALLOCATE | Yes | Never |
ON COMMIT DROP temp tables | Yes | Yes |
PRESERVE/DELETE ROWS temp tables | Yes | Never |
Cached plan reset | Yes | Yes |
LOAD statement | Yes | Never |
Session-level advisory locks | Yes | Never |
Startup parameters are: client_encoding
, DateStyle
, IntervalStyle
,
Timezone
, standard_conforming_strings
, and application_name
.
PgBouncer detects their changes and so it can guarantee they remain
consistent for the client. If you need PgBouncer to support more than
these, take a look at
track_extra_parameters
and
ignore_startup_parameters
. ↩
You need to change
max_prepared_statements
to a
non-zero value to enable this support. ↩