v1.22.0

_data/downloads.json

@@ -1,5 +1,15 @@
 {
   "series": [
+    [
+      {
+        "basever": "1.22",
+        "date": "2024-01-31",
+        "tgz_basename": "pgbouncer-1.22.0.tar.gz",
+        "tgz_file": "files/1.22.0/pgbouncer-1.22.0.tar.gz",
+        "tgz_size": 670589,
+        "version": "1.22.0"
+      }
+    ],
     [
       {
         "basever": "1.21",

_posts/2024-01-31-pgbouncer-1-22-0.md

@@ -0,0 +1,21 @@
+---
+layout: post
+title: PgBouncer 1.22.0
+category: pgbouncer
+---
+
+PgBouncer 1.22.0 has been released. The main feature this release adds is
+support for the `DISCARD ALL` and `DEALLOCATE ALL` commands when enabling
+prepared statement support in transaction pooling mode (by setting
+`max_prepared_statements` to a non-zero value). This is an important improvement
+in the prepared statement support that clears the road for us te be able to
+enabe prepared statement support by default in a future release.
+
+Other than that this release contains some small improvements and bugfixes,
+including improvements to our recommended SystemD configuration files.
+
+See the full details in the [changelog](/changelog.html#pgbouncer-122x).
+
+Download here:
+[pgbouncer-1.22.0.tar.gz](/downloads/files/1.22.0/pgbouncer-1.22.0.tar.gz)
+([sha256](/downloads/files/1.22.0/pgbouncer-1.22.0.tar.gz.sha256))

changelog.md

@@ -6,6 +6,38 @@ title: PgBouncer changelog
 PgBouncer changelog
 ===================
 
+PgBouncer 1.22.x
+----------------
+
+**2024-01-31  -  PgBouncer 1.22.0  -  "DEALLOCATE ALL"**
+
+- Features
+  * Adds support for `DEALLOCATE ALL` and `DISCARD ALL` when
+    `max_prepared_statements` is set to a non-zero value (normal `DEALLOCATE`
+    is still unsupported) ([#972])
+  * Support configuring `auth_query` per database ([#979])
+
+- Changes
+  * Improve settings in the recommended systemd unit file ([#983])
+  * Make fail fast logic handle all scenarios where no working connections to
+    the database exist anymore and none can be established ([#998])
+  * Multiple documentation improvements
+
+- Fixes
+  * Fix issue in PG14+ where PgBouncer would send `SET DateStyle='ISO'` for
+    every transaction ([#879])
+  * Fix handling of empty `application_name` ([#999])
+  * Fix building on Windows with OpenSSL 3.2.0 ([#1009])
+
+[#972]: https://github.com/pgbouncer/pgbouncer/pull/972
+[#979]: https://github.com/pgbouncer/pgbouncer/pull/979
+[#983]: https://github.com/pgbouncer/pgbouncer/pull/983
+[#998]: https://github.com/pgbouncer/pgbouncer/pull/998
+[#879]: https://github.com/pgbouncer/pgbouncer/pull/879
+[#999]: https://github.com/pgbouncer/pgbouncer/pull/999
+[#1009]: https://github.com/pgbouncer/pgbouncer/pull/1009
+
+
 PgBouncer 1.21.x
 ----------------
 

config.md

@@ -321,28 +321,32 @@ was originally prepared on another server connection.
 
 PgBouncer internally examines all the queries that are sent as a prepared
 statement by clients and gives each unique query string an internal name with
-the format `PGBOUNCER_{unique_id}`. Prepared statements are only prepared using
-this name on the corresponding PostgreSQL server. PgBouncer keeps track of the
-name that the client gave to each prepared statement. It rewrites each command
-that uses a prepared statement to use the matching internal name (e.g.
-`PGBOUNCER_123`) before forwarding that command to the server. More
-importantly, if the prepared statement that the client wants to use is not
-prepared on the server yet, it automatically prepares that statement before
-forwarding the command that the client sent.
+the format `PGBOUNCER_{unique_id}`. If the same query string is prepared
+multiple times (possibly by different clients), then these queries share the
+same internal name. PgBouncer only prepares the statement on the actual
+PostgreSQL server using the internal name (so not the name provided by the
+client). PgBouncer keeps track of the name that the client gave to each
+prepared statement. It then rewrites each command that uses a prepared
+statement to by replacing the client side name with the the internal name (e.g.
+replacing `my_prepared_stamenent` with `PGBOUNCER_123`) before forwarding that
+command to the server. More importantly, if the prepared statement that the
+client wants to execute is not yet prepared on the server (e.g. because a
+different server is now assigned to the client then when the client prepared
+the statement), then PgBouncer transparrently prepares the statement before
+executing it.
 
 Note: This tracking and rewriting of prepared statement commands does not work
-for SQL-level prepared statement commands such as `PREPARE`, `EXECUTE`,
-`DEALLOCATE`, `DEALLOCATE ALL` and `DISCARD ALL`. Running `DEALLOCATE ALL` and
-`DISCARD ALL` is especially problematic, since those commands appear to run
-successfully, but they mess up with the state of the server connection
-significantly without PgBouncer noticing. Which in turn will very likely break
-the execution of any further prepared statements on that server connection.
+for SQL-level prepared statement commands, so `PREPARE`, `EXECUTE` and
+`DEALLOCATE` are forwarded straight to Postgres. The exception to this rule are
+the `DEALLOCATE ALL` and `DISCARD ALL` commands, these do work as expected and
+will clear the prepared statements that PgBouncer tracked for the client that
+sends this command.
 
 The actual value of this setting controls the number of prepared statements
-kept active on a single server connection. When the setting is set to 0
-prepared statement support for transaction and statement pooling is disabled.
-To get the best performance you should try to make sure that this setting is
-larger than the amount of commonly used prepared statements in your
+kept active in an LRU cache on a single server connection. When the setting is
+set to 0 prepared statement support for transaction and statement pooling is
+disabled. To get the best performance you should try to make sure that this
+setting is larger than the amount of commonly used prepared statements in your
 application. Keep in mind that the higher this value, the larger the memory
 footprint of each PgBouncer connection will be on your PostgreSQL server,
 because it will keep more queries prepared on those connections. It also
@@ -1174,6 +1178,14 @@ If no password is specified here, the password from the `auth_file` or
 
 Override of the global `auth_user` setting, if specified.
 
+### auth_query
+
+Override of the global `auth_query` setting, if specified. The entire SQL statement needs to be enclosed in single quotes.
+
+### auth_dbname
+
+Override of the global `auth_dbname` setting, if specified.
+
 ### pool_size
 
 Set the maximum size of pools for this database.  If not set,

downloads/files/1.22.0/pgbouncer-1.22.0.tar.gz.sha256

@@ -0,0 +1 @@
+c6ee37a8d7ddbebbf8442d8f08ec07c3da46afb2aae3967388c1481698a77858  pgbouncer-1.22.0.tar.gz

usage.md

@@ -189,7 +189,7 @@ total_xact_count
 :   Total number of SQL transactions pooled by **pgbouncer**.
 
 total_query_count
-:   Total number of SQL queries pooled by **pgbouncer**.
+:   Total number of SQL commands pooled by **pgbouncer**.
 
 total_received
 :   Total volume in bytes of network traffic received by **pgbouncer**.
@@ -473,7 +473,9 @@ pools
 :   Count of pools.
 
 free_clients
-:   Count of 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 a future clients to avoid allocations.
 
 used_clients
 :   Count of used clients.
@@ -482,7 +484,9 @@ login_clients
 :   Count of clients in **login** state.
 
 free_servers
-:   Count of 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 a future servers to avoid allocations.
 
 used_servers
 :   Count of used servers.