PGBOUNCER(1)

📦
version 1.26.1 · 14 versions
, in fedora 44, nixos 26.05, nixpkgs unstable

👑 PGBOUNCER(1) — the pgbouncer(1) glow-up 🦋

okay so bestie, sit down, hydrate, and get comfy, because we're about to read the manual page for pgbouncer — that's the lightweight connection pooler for PostgreSQL — and honestly? It's giving main character energy for your database layer. 💅

✨ NAME ✨

pgbouncer — a lightweight connection pooler for PostgreSQL. That's the whole vibe. 🫶

🌈 SYNOPSIS 🌈

The classic:

pgbouncer [-d][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

And on Windows, the options are:

pgbouncer.exe [-v][-u user] <pgbouncer.ini>
pgbouncer.exe -V|-h

Additional options for setting up a Windows service:

pgbouncer.exe --regservice   <pgbouncer.ini>
pgbouncer.exe --unregservice <pgbouncer.ini>

💖 DESCRIPTION 💖

So like, pgbouncer is a PostgreSQL connection pooler. Any target application can connect to pgbouncer like it's just a regular PostgreSQL server — no cap — and then pgbouncer will either create a connection to the actual server, or it'll reuse one of the connections it already has sitting there. Iconic recycling behavior. ♻️

The whole point, the ~aim~ of pgbouncer, is to lower the performance impact of opening new connections to PostgreSQL. Opening fresh connections is expensive; pgbouncer said "not on my watch." 💀

And here's the important part: so that it doesn't compromise transaction semantics for connection pooling, pgbouncer supports several types of pooling when rotating connections:

  • Session pooling — the most polite method. When a client connects, a server connection gets assigned to it for the whole duration the client stays connected. When the client disconnects, the server connection gets put back into the pool. This is the default method. 🎀
  • Transaction pooling — a server connection is assigned to a client only during a transaction. When PgBouncer notices that the transaction is over, the server connection gets put back into the pool. ✨
  • Statement pooling — the most aggressive method. The server connection gets put back into the pool immediately after a query completes. Multi-statement transactions are disallowed in this mode because they would break. 🫠

And the administration interface of pgbouncer? It consists of some new SHOW commands that are available when you're connected to a special "virtual" database called pgbouncer. Very exclusive, very VIP. 👑

🚀 QUICK-START 🚀

Basic setup and usage is as follows, bestie. Follow along:

  1. Create a pgbouncer.ini file. Details in pgbouncer(5). Simple example:
[databases]
template1 = host=localhost port=5432 dbname=template1

[pgbouncer]
listen_port = 6432
listen_addr = localhost
auth_type = md5
auth_file = userlist.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser
  1. Create a userlist.txt file that contains the users allowed in:
"someuser" "same_password_as_in_server"
  1. Launch pgbouncer:
$ pgbouncer -d pgbouncer.ini
  1. Have your application (or the psql client) connect to pgbouncer instead of directly to the PostgreSQL server:
$ psql -p 6432 -U someuser template1
  1. Manage pgbouncer by connecting to the special administration database pgbouncer and issuing SHOW HELP; to begin:
$ psql -p 6432 -U someuser pgbouncer
pgbouncer=# SHOW HELP;
NOTICE:  Console usage
DETAIL:
  SHOW [HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|SOCKETS|LISTS|VERSION|...]
  SET key = arg
  RELOAD
  PAUSE
  RESUME
  SHUTDOWN
  [...]
  1. If you made changes to the pgbouncer.ini file, you can reload it with:
pgbouncer=# RELOAD;

Slay. You're basically a DBA now. 🌈

🎀 COMMAND LINE SWITCHES 🎀

  • -d, --daemon — run in the background. Without it, the process runs in the foreground. 🌀

Heads up: in daemon mode, setting pidfile as well as logfile or syslog is required. No log messages will be written to stderr after going into the background.

Note: does not work on Windows; pgbouncer needs to run as a service there.
  • -u USERNAME, --user=USERNAME — switch to the given user on startup. 🫶
  • -v, --verbose — increase verbosity. Can be used multiple times. (Yes bestie, stack them. Go off.) 🔥
  • -q, --quiet — be quiet: do not log to stderr. This does not affect logging verbosity — only that stderr is not to be used. For use in init.d scripts. 🤫
  • -V, --version — show version. ⭐
  • -h, --help — show short help. 💜
  • --regservice — Win32: register PgBouncer to run as a Windows service. The service_name configuration parameter value is used as the name to register under. 🪟
  • --unregservice — Win32: unregister the Windows service. 🪟

💅 ADMIN CONSOLE 💅

The console is available by connecting as normal to the database pgbouncer:

$ psql -p 6432 pgbouncer

Only users listed in the configuration parameters admin_users or stats_users are allowed to log in to the console. (Except when auth_type=any, then any user is allowed in as a stats_user.) 🎟️

Additionally, the user name pgbouncer is allowed to log in without a password, if the login comes via the Unix socket and the client has the same Unix user UID as the running process. ✨

Real talk: the admin console currently only supports the simple query protocol. Some drivers use the extended query protocol for all commands; those drivers will not work for this. 😭 Not their fault, but also not pgbouncer's problem.

🌸 Show commands 🌸

The SHOW commands output information. Each command is described below. 🦋

🌟 SHOW STATS 🌟

Shows statistics. In this and related commands, the total figures are since process start, and the averages are updated every stats_period. 📊

  • database — statistics are presented per database.
  • total_xact_count — total number of SQL transactions pooled by pgbouncer.
  • total_query_count — total number of SQL commands pooled by pgbouncer.
  • total_server_assignment_count — total times a server was assigned to a client.
  • total_received — total volume in bytes of network traffic received by pgbouncer.
  • total_sent — total volume in bytes of network traffic sent by pgbouncer.
  • total_xact_time — total number of microseconds spent by pgbouncer when connected to PostgreSQL in a transaction, either idle in transaction or executing queries.
  • total_query_time — total number of microseconds spent by pgbouncer when actively connected to PostgreSQL, executing queries.
  • total_wait_time — time spent by clients waiting for a server, in microseconds. Updated when a client connection is assigned a backend connection.
  • total_client_parse_count — total number of prepared statements created by clients. Only applicable in named prepared statement tracking mode, see max_prepared_statements.
  • total_server_parse_count — total number of prepared statements created by pgbouncer on a server. Only applicable in named prepared statement tracking mode, see max_prepared_statements.
  • total_bind_count — total number of prepared statements readied for execution by clients and forwarded to PostgreSQL by pgbouncer. Only applicable in named prepared statement tracking mode, see max_prepared_statements.
  • total_client_login_count — total number of successful client logins.
  • avg_xact_count — average transactions per second in last stat period.
  • avg_query_count — average queries per second in last stat period.
  • avg_server_assignment_count — average number of times a server was assigned to a client per second in the last stat period.
  • avg_recv — average received (from clients) bytes per second.
  • avg_sent — average sent (to clients) bytes per second.
  • avg_xact_time — average transaction duration, in microseconds.
  • avg_query_time — average query duration, in microseconds.
  • avg_wait_time — time spent by clients waiting for a server, in microseconds (average of the wait times for clients assigned a backend during the current stats_period).
  • avg_client_parse_count — average number of prepared statements created by clients. Only applicable in named prepared statement tracking mode, see max_prepared_statements.
  • avg_server_parse_count — average number of prepared statements created by pgbouncer on a server. Only applicable in named prepared statement tracking mode, see max_prepared_statements.
  • avg_bind_count — average number of prepared statements readied for execution by clients and forwarded to PostgreSQL by pgbouncer. Only applicable in named prepared statement tracking mode, see max_prepared_statements.
  • avg_client_login_count — average number of successful client logins per second.

⭐ SHOW STATS_TOTALS ⭐

A subset of SHOW STATS showing the total values (total_). 🧮

⭐ SHOW STATS_AVERAGES ⭐

A subset of SHOW STATS showing the average values (avg_). 📈

🌈 SHOW TOTALS 🌈

Like SHOW STATS but aggregated across all databases. The big picture, bestie. 🫶

🦋 SHOW SERVERS 🦋

  • type — S, for server.
  • user — user name pgbouncer uses to connect to server.
  • database — database name.
  • replication — if the server connection uses replication. Can be none, logical or physical.
  • state — state of the PgBouncer server connection, one of active, idle, used, tested, new, active_cancel, being_canceled.
  • addr — IP address of the PostgreSQL server.
  • port — port of the PostgreSQL server.
  • local_addr — connection start address on local machine.
  • local_port — connection start port on local machine.
  • connect_time — when the connection was made.
  • request_time — when the last request was issued.
  • wait — not used for server connections.
  • wait_us — not used for server connections.
  • close_needed — 1 if the connection will be closed as soon as possible, because a configuration file reload or DNS update changed the connection information or RECONNECT was issued.
  • ptr — address of internal object for this connection.
  • link — address of client connection the server is paired with.
  • remote_pid — PID of backend server process. In case the connection is made over Unix socket and the OS supports getting process ID info, its OS PID. Otherwise it's extracted from the cancel packet the server sent, which should be the PID in case the server is PostgreSQL, but it's a random number in case the server is another PgBouncer. 🙈
  • tls — a string with TLS connection information, or empty if not using TLS.
  • application_name — a string containing the application_name set on the linked client connection, or empty if this is not set, or if there is no linked connection.

okay that's part one, and there's more coming so don't go anywhere bestie 🎀

  • prepared_statements — how many prepared statements are currently prepped on the server. The ceiling for this is the max_prepared_statements setting, so that's the vibe limit 💅
  • id — the server's unique ID, like its own little name tag 🏷️

🦋 SHOW CLIENTS 🦋

  • type — it's C, for client. Obviously 💁‍♀️
  • user — the client's connected user.
  • database — database name, bestie.
  • replication — whether the client connection uses replication. Can be none, logical, or physical.
  • state — the client connection's state, and it's one of: active (client connections linked to server connections), idle (client connections with no queries waiting to be processed), waiting, active_cancel_req, or waiting_cancel_req.
  • addr — the client's IP address.
  • port — the client's source port.
  • local_addr — the connection end address on the local machine.
  • local_port — the connection end port on the local machine.
  • connect_time — timestamp of when the connection happened.
  • request_time — timestamp of the latest client request.
  • wait — the current waiting time, in seconds.
  • wait_us — the microsecond part of that current waiting time.
  • close_needed — literally not used for clients 🙈
  • ptr — the address of the internal object for this connection.
  • link — the address of the server connection this client is paired with.
  • remote_pid — process ID, in case the client connects over a Unix socket and the OS supports getting it.
  • tls — a string with TLS connection info, or empty if TLS isn't being used.
  • application_name — a string containing the application_name set by the client for this connection, or empty if it wasn't set.
  • prepared_statements — the amount of prepared statements the client has prepared.
  • id — unique ID for the client. Every main character needs one 👑

🌸 SHOW POOLS 🌸

A new pool entry gets made for each (database, user) couple. It's giving paired-up dynamic duo energy 💖

  • database — database name.
  • user — user name.
  • cl_active — client connections that are either linked to server connections, or idle with no queries waiting to be processed.
  • cl_waiting — client connections that have sent queries but haven't gotten a server connection yet. They're in line, bestie 😭
  • cl_active_cancel_req — client connections that have forwarded query cancellations to the server and are waiting for the server response.
  • cl_waiting_cancel_req — client connections that haven't forwarded query cancellations to the server yet.
  • sv_active — server connections that are linked to a client.
  • sv_active_cancel — server connections that are currently forwarding a cancel request.
  • sv_being_canceled — servers that normally could become idle, but are waiting to do so until all in-flight cancel requests have completed. Those are the requests sent to cancel a query on this server, btw.
  • sv_idle — server connections that are unused and immediately usable for client queries. Iconic availability ✨
  • sv_used — server connections that have been idle for more than server_check_delay, so server_check_query needs to run on them before they can be used again.
  • sv_tested — server connections currently running either server_reset_query or server_check_query.
  • sv_login — server connections currently in the process of logging in.
  • maxwait — how long the first (aka oldest) client in the queue has waited, in seconds.
If this starts increasing, then the current pool of servers isn't handling requests quickly enough. The reason may be either an overloaded server or just too small of a pool_size setting. That's your cue to look at it, bestie 💀
  • maxwait_us — the microsecond part of the maximum waiting time.
  • pool_mode — the pooling mode in use.
  • load_balance_hosts — the load_balance_hosts in use, if the pool's host contains a comma-separated list.

🎀 SHOW PEER_POOLS 🎀

A new peer_pool entry gets made for each configured peer. Peer pool era 🫶

  • peer_id — ID of the configured peer entry.
  • cl_active_cancel_req — client connections that have forwarded query cancellations to the server and are waiting for the server response.
  • cl_waiting_cancel_req — client connections that haven't forwarded query cancellations to the server yet.
  • sv_active_cancel — server connections that are currently forwarding a cancel request.
  • sv_login — server connections currently in the process of logging in.

🌈 SHOW LISTS 🌈

Shows the following internal info, in columns (not rows — yes, it's that kind of layout, don't come for me):

  • databases — count of databases.
  • users — count of users.
  • pools — count of pools.
  • free_clients — count of free clients. These are clients that are disconnected, but PgBouncer keeps the memory around that was allocated for them so it can be reused for future clients and avoid allocations.
  • used_clients — count of used clients.
  • login_clients — count of clients in login state.
  • free_servers — count of free servers. These are servers that are disconnected, but PgBouncer keeps the memory around that was allocated for them so it can be reused for future servers and avoid allocations.
  • used_servers — count of used servers.
  • dns_names — count of DNS names in the cache.
  • dns_zones — count of DNS zones in the cache.
  • dns_queries — count of in-flight DNS queries.
  • dns_pending — not used 🙃

💜 SHOW USERS 💜

  • name — the user name.
  • pool_size — the user's override pool_size, or NULL if not set.
  • reserve_pool_size — the user's override reserve_pool_size, or NULL if not set.
  • pool_mode — the user's override pool_mode, or NULL if not set.
  • max_user_connections — the user's max_user_connections setting. If this setting isn't set for this specific user, then the default value will be displayed.
  • current_connections — current number of server connections that this user has open to all servers.
  • max_user_client_connections — the user's max_user_client_connections setting. If this setting isn't set for this specific user, then the default value will be displayed.
  • current_client_connections — current number of client connections that this user has open to PgBouncer.

🦋 SHOW DATABASES 🦋

  • name — name of the configured database entry.
  • host — host PgBouncer connects to.
  • port — port PgBouncer connects to.
  • database — actual database name PgBouncer connects to.
  • force_user — when the user is part of the connection string, the connection between PgBouncer and PostgreSQL is forced to the given user, whatever the client user. No negotiating 💅
  • pool_size — maximum number of server connections.
  • min_pool_size — minimum number of server connections.
  • reserve_pool_size — maximum number of additional connections for this database.
  • server_lifetime — the maximum lifetime of a server connection for this database.
  • pool_mode — the database's override pool_mode, or NULL if the default will be used instead.
  • load_balance_hosts — the database's load_balance_hosts, if the host contains a comma-separated list.
  • max_connections — maximum number of allowed server connections for this database, as set by max_db_connections, either globally or per database.
  • current_connections — current number of server connections for this database.
  • max_client_connections — maximum number of allowed client connections for this PgBouncer instance, as set by max_db_client_connections per database.
  • current_client_connections — current number of client connections for this database.
  • paused — 1 if this database is currently paused, else 0.
  • disabled — 1 if this database is currently disabled, else 0.

🌸 SHOW PEERS 🌸

  • peer_id — ID of the configured peer entry.
  • host — host PgBouncer connects to.
  • port — port PgBouncer connects to.
  • pool_size — maximum number of server connections that can be made to this peer.

🫶 SHOW SOCKETS, SHOW ACTIVE_SOCKETS 🫶

Shows low-level info about sockets — or only active sockets, when you use the active version. This includes the info shown under SHOW CLIENTS and SHOW SERVERS, plus other more low-level information. It's the behind-the-scenes lore ✨

💅 SHOW CONFIG 💅

Shows the current configuration settings, one per row, with these columns:

  • key — configuration variable name.
  • value — configuration value.
  • default — configuration default value.
  • changeable — either yes or no, showing if the variable can be changed while running. If no, the variable can be changed only at boot time. Use SET to change a variable at run time.

🧚 SHOW MEM 🧚

Shows low-level info about the current sizes of various internal memory allocations. The information presented is subject to change — so don't get too attached, bestie.

🍓 SHOW DNS_HOSTS 🍓

Shows host names in the DNS cache.

  • hostname — host name.
  • ttl — how many seconds until the next lookup.
  • addrs — comma-separated list of addresses.

👑 SHOW DNS_ZONES 👑

Shows DNS zones in the cache.

  • zonename — zone name.
  • serial — current serial.
  • count — host names belonging to this zone.

⭐ SHOW VERSION ⭐

Shows the PgBouncer version string. Slay, version reveal 💖

🎮 SHOW STATE 🎮

Shows the PgBouncer state settings. Current states are active and paused.

🔥 PROCESS CONTROLLING COMMANDS 🔥

💅 PAUSE [db] 💅

PgBouncer tries to disconnect from all servers. Disconnecting each server connection waits for that server connection to be released according to the server pool's pooling mode — in transaction pooling mode, the transaction must complete; in statement mode, the statement must complete; and in session pooling mode, the client must disconnect. The command will not return before all server connections have been disconnected. To be used at the time of database restart.

If a database name is given, only that database will be paused.

New client connections to a paused database will wait until RESUME is called. So yes, they're waiting outside like 🧍‍♀️🧍‍♀️🧍‍♀️

🎀 DISABLE db 🎀

Reject all new client connections on the given database. Not today, new clients 💀

✨ ENABLE db ✨

Allow new client connections after a previous DISABLE command. Welcome back, besties 🫶

🌈 RECONNECT [db] 🌈

Close each open server connection for the given database — or all databases — after it's released (according to the pooling mode), even if its lifetime isn't up yet. New server connections can be made immediately and will connect as necessary according to the pool size settings. Fresh connections, no cap 🔥

okay so this command is useful when the server connection setup has changed — like, say, you want to do a gradual switchover to a new server. 🦋 It is not necessary to run this command when the connection string in pgbouncer.ini has been changed and reloaded (see RELOAD) or when DNS resolution has changed, because then the equivalent of this command will be run automatically. This command is only necessary if something downstream of PgBouncer routes the connections. iykyk 💅

After this command is run, there could be an extended period where some server connections go to an old destination and some server connections go to a new destination. This is likely only sensible when switching read-only traffic between read-only replicas, or when switching between nodes of a multimaster replication setup. If all connections need to be switched at the same time, PAUSE is recommended instead. To close server connections without waiting (for example, in emergency failover rather than gradual switchover scenarios), also consider KILL. 🔥

💅 KILL [db]

Immediately drop all client and server connections on the given database or all databases, excluding the admin database. no cap 🫶

New client connections to a killed database will wait until RESUME is called.

💅 KILL_CLIENT id

Immediately kill the specified client connection along with any server connections for the given client. The client to kill is identified by the id value that can be found using the SHOW CLIENTS command. 👑

An example command will look something like KILL_CLIENT 1234.

💅 RESUME [db]

Resume work from a previous KILL or PAUSE command. we love a comeback era ✨

💅 SHUTDOWN

The PgBouncer process will exit. bye bestie 💀

🛑 SHUTDOWN WAIT_FOR_SERVERS

Stop accepting new connections and shutdown after all servers are released. This is basically the same as issuing PAUSE and SHUTDOWN, except that this also stops accepting new connections while waiting for the PAUSE as well as eagerly disconnecting clients that are waiting to receive a server connection. Please note that UNIX sockets will remain open during the shutdown but will only accept connections to the PgBouncer admin console. 🧚

🛑 SHUTDOWN WAIT_FOR_CLIENTS

Stop accepting new connections and shutdown the process once all existing clients have disconnected. Please note that UNIX sockets will remain open during the shutdown but will only accept connections to the pgbouncer admin console. This command can be used to do zero-downtime rolling restart of two PgBouncer processes using the following procedure: 🌈

  1. Have two or more PgBouncer processes running on the same port using so_reuseport (configuring peering is recommended, but not required). To achieve zero downtime when restarting we’ll restart these processes one-by-one, thus leaving the others running to accept connections while one is being restarted.
  2. Pick a process to restart first, let’s call it A.
  3. Run SHUTDOWN WAIT_FOR_CLIENTS (or send SIGTERM) to process A.
  4. Cause all clients to reconnect. Possibly by waiting some time until the client side pooler causes reconnects due to its server_idle_timeout (or similar config). Or if no client side pooler is used, possibly by restarting the clients. Once all clients have reconnected, process A will exit automatically, because no clients are connected to it anymore.
  5. Start process A again.
  6. Repeat step 3, 4 and 5 for each of the remaining processes, one-by-one until you restarted all processes.

💅 RELOAD

The PgBouncer process will reload its configuration files and update changeable settings. This includes the main configuration file as well as the files specified by the settings auth_file and auth_hba_file. 🎀

PgBouncer notices when a configuration file reload changes the connection parameters of a database definition. An existing server connection to the old destination will be closed when the server connection is next released (according to the pooling mode), and new server connections will immediately use the updated connection parameters. obsessssed with a clean reload ✨

💅 WAIT_CLOSE [db]

Wait until all server connections, either of the specified database or of all databases, have cleared the close_needed state (see SHOW SERVERS). This can be called after a RECONNECT or RELOAD to wait until the respective configuration change has been fully activated, for example in switchover scripts. 🦋

✨ Other commands ✨

💅 SET key = arg

Changes a configuration setting (see also SHOW CONFIG). For example:

SET log_connections = 1;
SET server_check_query = 'select 2';

(Note that this command is run on the PgBouncer admin console and sets PgBouncer settings. A SET command run on another database will be passed to the PostgreSQL backend like any other SQL command.) 💜

📡 Signals 📡

  • SIGHUP — Reload config. Same as issuing the command RELOAD on the console.
  • SIGTERM — Super safe shutdown. Wait for all existing clients to disconnect, but don’t accept new connections. This is the same as issuing SHUTDOWN WAIT_FOR_CLIENTS on the console. If this signal is received while there is already a shutdown in progress, then an “immediate shutdown” is triggered instead of a “super safe shutdown”. In PgBouncer versions earlier than 1.23.0, this signal would cause an “immediate shutdown”. 😭
  • SIGINT — Safe shutdown. Same as issuing SHUTDOWN WAIT_FOR_SERVERS on the console. If this signal is received while there is already a shutdown in progress, then an “immediate shutdown” is triggered instead of a “safe shutdown”.
  • SIGQUIT — Immediate shutdown. Same as issuing SHUTDOWN on the console.
  • SIGUSR1 — Same as issuing PAUSE on the console.
  • SIGUSR2 — Same as issuing RESUME on the console.

🌈 Libevent settings 🌈

From the Libevent documentation:

It is possible to disable support for epoll, kqueue, devpoll, poll or select by setting the environment variable EVENT_NOEPOLL, EVENT_NOKQUEUE, EVENT_NODEVPOLL, EVENT_NOPOLL or EVENT_NOSELECT, respectively. By setting the environment variable EVENT_SHOW_METHOD, libevent displays the kernel notification method that it uses.

🫶 SEE ALSO 🫶

signing off from the PGBOUNCER(1) page, version 1.26.1 — mwah, bestie 💋💖

📦 where this page comes from