Dokumentation zu PgBouncer 1.26.0

• 1: Funktionen
• 2: Konfiguration: pgbouncer.ini
• 3: Verwendung: pgbouncer-Befehl
• 4: PgBouncer kompilieren und installieren
• 5: Quellcode-Releases zum Download
• 6: Änderungsprotokoll
• 7: Community
• 8: Häufig gestellte Fragen

1 - Funktionen

• Mehrere Pooling-Modi mit unterschiedlich restriktiver Verbindungszuweisung:

  Sitzungs-Pooling

  Die am wenigsten restriktive Methode. Wenn ein Client eine Verbindung herstellt, wird ihm für die gesamte Dauer der Clientverbindung eine Serververbindung zugewiesen. Trennt der Client die Verbindung, wird die Serververbindung wieder in den Pool zurückgegeben. Dieser Modus unterstützt sämtliche PostgreSQL-Funktionen.

  Transaktions-Pooling

  Eine Serververbindung wird einem Client nur für die Dauer einer Transaktion zugewiesen. Sobald PgBouncer erkennt, dass die Transaktion beendet ist, wird die Serververbindung wieder in den Pool zurückgegeben. Dieser Modus ist mit einigen sitzungsbezogenen Funktionen von PostgreSQL nicht kompatibel. Er kann nur eingesetzt werden, wenn die Anwendung darauf abgestimmt ist und keine inkompatiblen Funktionen verwendet. Die folgende Tabelle führt diese Funktionen auf.

  Statement-Pooling

  Die restriktivste Methode. Sie entspricht dem Transaktions-Pooling, lässt jedoch keine Transaktionen mit mehreren Anweisungen zu. Damit wird auf der Clientseite der „Autocommit“-Modus erzwungen; der Modus ist vor allem für PL/Proxy vorgesehen.

• Geringer Speicherbedarf (standardmäßig 2 kB pro Verbindung), da PgBouncer vollständige Pakete nicht auf einmal einlesen muss.

• PgBouncer ist nicht an einen einzelnen Backend-Server gebunden. Die Zieldatenbanken können sich auf unterschiedlichen Hosts befinden.

• Unterstützt für die meisten Einstellungen eine Neukonfiguration im laufenden Betrieb.

• Unterstützt rollierende Neustarts und Upgrades mit mehreren Prozessen und so_reuseport . Der bisherige Neustart im laufenden Betrieb (-R) wurde in 1.26.0 entfernt.

SQL-Funktionsmatrix für Pooling-Modi

Die folgende Tabelle zeigt verschiedene PostgreSQL-Funktionen und ihre Kompatibilität mit den Pooling-Modi von PgBouncer. Beachten Sie, dass das Transaktions-Pooling das vom Client erwartete Serververhalten bewusst verändert. Es kann daher nur verwendet werden, wenn die Anwendung darauf abgestimmt ist und keine inkompatiblen Funktionen nutzt.

2 - Konfiguration: pgbouncer.ini

Beschreibung

Die Konfigurationsdatei verwendet das „ini“-Format. Abschnittsnamen stehen zwischen [ und ]. Zeilen, die mit ; oder # beginnen, werden als Kommentare betrachtet und ignoriert. Treten die Zeichen ; und # später in einer Zeile auf, haben sie keine besondere Bedeutung.

Allgemeine Einstellungen

logfile

Gibt die Protokolldatei an. Für den Daemon-Betrieb (-d) muss entweder diese Einstellung oder syslog gesetzt sein.

Die Protokolldatei bleibt geöffnet. Nach einer Rotation sollte daher kill -HUP oder in der Konsole RELOAD; ausgeführt werden. Unter Windows muss der Dienst gestoppt und wieder gestartet werden.

Das Setzen von logfile allein schaltet die Protokollierung auf stderr nicht ab. Dazu dient die Befehlszeilenoption -q oder -d.

Standard: nicht gesetzt

pidfile

Gibt die PID-Datei an. Ohne gesetztes pidfile ist der Daemon-Betrieb (-d) nicht zulässig.

Standard: nicht gesetzt

listen_addr

Gibt eine durch Kommas getrennte Liste von Adressen an, an denen auf TCP-Verbindungen gewartet wird. Mit * kann auf allen Adressen gewartet werden. Ist die Einstellung nicht gesetzt, werden nur Verbindungen über Unix-Sockets angenommen.

Adressen können numerisch (IPv4/IPv6) oder als Name angegeben werden.

Standard: nicht gesetzt

listen_port

Port, an dem auf Verbindungen gewartet wird. Gilt sowohl für TCP als auch für Unix-Sockets.

Standard: 6432

unix_socket_dir

Gibt das Verzeichnis für Unix-Sockets an. Gilt sowohl für den lauschenden Socket als auch für Serververbindungen. Bei einer leeren Zeichenfolge sind Unix-Sockets deaktiviert. Ein mit @ beginnender Wert legt fest, dass ein Unix-Socket im abstrakten Namensraum erstellt werden soll (derzeit unter Linux und Windows unterstützt).

Standard: /tmp (unter Windows leer)

unix_socket_mode

Dateisystemmodus für Unix-Sockets. Wird für Sockets im abstrakten Namensraum ignoriert. Unter Windows nicht unterstützt.

Standard: 0777

unix_socket_group

Gruppenname für Unix-Sockets. Wird für Sockets im abstrakten Namensraum ignoriert. Unter Windows nicht unterstützt.

Standard: nicht gesetzt

user

Falls gesetzt, gibt diese Einstellung den Unix-Benutzer an, zu dem nach dem Start gewechselt wird. Funktioniert nur, wenn PgBouncer als root gestartet wird oder bereits unter dem angegebenen Benutzer läuft. Unter Windows nicht unterstützt.

Standard: nicht gesetzt

pool_mode

Legt fest, wann eine Serververbindung von anderen Clients wiederverwendet werden kann.

• session: Die Serververbindung wird an den Pool zurückgegeben, nachdem der Client die Verbindung getrennt hat. Standard.
• transaction: Die Serververbindung wird nach Abschluss der Transaktion an den Pool zurückgegeben.
• statement: Die Serververbindung wird nach Abschluss der Abfrage an den Pool zurückgegeben. Transaktionen über mehrere Anweisungen sind in diesem Modus nicht zulässig.

max_client_conn

Maximal zulässige Anzahl von Clientverbindungen.

Wird diese Einstellung erhöht, müssen möglicherweise auch die Grenzen für Dateideskriptoren im Betriebssystem erhöht werden. Die Anzahl der potenziell verwendeten Dateideskriptoren liegt über max_client_conn. Verbindet sich jeder Benutzer unter seinem eigenen Benutzernamen mit dem Server, beträgt das theoretische Maximum:

max_client_conn + (max pool_size * total databases * total users)

Wird in der Verbindungszeichenfolge ein Datenbankbenutzer angegeben (alle Benutzer verbinden sich unter demselben Benutzernamen), beträgt das theoretische Maximum:

max_client_conn + (max pool_size * total databases)

Das theoretische Maximum sollte nie erreicht werden, sofern nicht gezielt eine spezielle Last dafür erzeugt wird. Dennoch sollte die Grenze für Dateideskriptoren ausreichend hoch angesetzt werden.

Suchen Sie in der Handbuchseite Ihrer bevorzugten Shell nach ulimit. Hinweis: ulimit gilt nicht in einer Windows-Umgebung.

Standard: 100

default_pool_size

Maximal zulässige Anzahl von Serververbindungen pro Benutzer/Datenbank-Paar. Kann durch pool_size in der datenbank- und benutzerspezifischen Konfiguration überschrieben werden; dieser Standardwert wird verwendet, wenn für eine bestimmte Datenbank oder einen bestimmten Benutzer kein eigener Wert für pool_size angegeben ist.

Standard: 20

min_pool_size

Fügt dem Pool weitere Serververbindungen hinzu, wenn ihre Anzahl unter diesem Wert liegt. Verbessert das Verhalten, wenn nach einer Phase völliger Inaktivität plötzlich wieder die normale Last einsetzt. Der Wert wird effektiv auf die Poolgröße begrenzt.

Wird nur für Pools durchgesetzt, für die mindestens eine der folgenden Bedingungen zutrifft:

• Im Eintrag des Pools im Abschnitt [databases] ist für den Schlüssel user ein Wert gesetzt (ein sogenannter erzwungener Benutzer).
• Mindestens ein Client ist mit dem Pool verbunden.

Standard: 0 (deaktiviert)

reserve_pool_size

Anzahl zusätzlicher Verbindungen, die für einen Pool zugelassen werden (siehe reserve_pool_timeout). 0 deaktiviert diese Funktion.

Standard: 0 (deaktiviert)

reserve_pool_timeout

Wurde ein Client innerhalb dieser Zeit nicht bedient, werden zusätzliche Verbindungen aus dem Reservepool verwendet. 0 deaktiviert diese Funktion. [Sekunden]

Standard: 5.0

max_db_connections

Lässt pro Datenbank höchstens diese Anzahl von Serververbindungen zu (unabhängig vom Benutzer). Maßgeblich ist die PgBouncer-Datenbank, mit der sich der Client verbunden hat, nicht die PostgreSQL-Datenbank der ausgehenden Verbindung.

Kann auch pro Datenbank im Abschnitt [databases] gesetzt werden.

Ist die Grenze erreicht, ermöglicht das Schließen einer Clientverbindung zu einem Pool nicht sofort eine neue Serververbindung für einen anderen Pool, da die Serververbindung des ersten Pools noch geöffnet ist. Sobald diese Serververbindung geschlossen wird (wegen Überschreitung der Leerlaufzeit), wird unmittelbar eine neue Serververbindung für den wartenden Pool geöffnet.

Standard: 0 (unbegrenzt)

max_db_client_connections

Lässt pro Datenbank höchstens diese Anzahl von Clientverbindungen zu PgBouncer zu (unabhängig vom Benutzer). Maßgeblich ist die PgBouncer-Datenbank, mit der sich der Client verbunden hat, nicht die PostgreSQL-Datenbank der ausgehenden Verbindung.

Dieser Wert sollte mindestens so groß wie max_db_connections sein. Die Differenz zwischen den beiden Werten lässt sich als Anzahl der Verbindungen zu einer bestimmten Datenbank verstehen, die in der Warteschlange auf den Abschluss aktiver Verbindungen warten können.

Kann auch pro Datenbank im Abschnitt [databases] gesetzt werden.

Standard: 0 (unbegrenzt)

max_user_connections

Lässt pro Benutzer höchstens diese Anzahl von Serververbindungen zu (unabhängig von der Datenbank). Maßgeblich ist der dem Pool zugeordnete PgBouncer-Benutzer: entweder der für die Serververbindung angegebene Benutzer oder, falls keiner angegeben ist, der Benutzer, als der sich der Client verbunden hat.

Kann auch pro Benutzer im Abschnitt [users] gesetzt werden.

Ist die Grenze erreicht, ermöglicht das Schließen einer Clientverbindung zu einem Pool nicht sofort eine neue Serververbindung für einen anderen Pool, da die Serververbindung des ersten Pools noch geöffnet ist. Sobald diese Serververbindung geschlossen wird (wegen Überschreitung der Leerlaufzeit), wird unmittelbar eine neue Serververbindung für den wartenden Pool geöffnet.

Standard: 0 (unbegrenzt)

max_user_client_connections

Lässt pro Benutzer höchstens diese Anzahl von Clientverbindungen zu (unabhängig von der Datenbank). Dieser Wert sollte größer als max_user_connections sein. Die Differenz zwischen max_user_connections und max_user_client_connections lässt sich als maximale Größe der Warteschlange für den Benutzer verstehen.

Kann auch pro Benutzer im Abschnitt [users] gesetzt werden.

Standard: 0 (unbegrenzt)

server_round_robin

Standardmäßig verwendet PgBouncer Serververbindungen nach dem LIFO-Prinzip (zuletzt hinein, zuerst heraus) wieder, sodass wenige Verbindungen den Großteil der Last tragen. Dies bietet die beste Leistung, wenn eine Datenbank von einem einzelnen Server bedient wird. Steht hinter einer Datenbankadresse jedoch ein Round-Robin-System (TCP, DNS oder eine Hostliste), ist es besser, wenn PgBouncer Verbindungen ebenfalls nach diesem Verfahren nutzt und so die Last gleichmäßig verteilt.

Standard: 0

track_extra_parameters

Standardmäßig verfolgt PgBouncer alle Parameter, die Postgres an den Client meldet und die der Client ändern kann:

• application_name
• client_encoding
• DateStyle
• default_transaction_read_only
• IntervalStyle
• scram_iterations (seit PostgreSQL-Version 16)
• search_path (seit PostgreSQL-Version 18)
• session_authorization
• standard_conforming_strings
• TimeZone

Weitere zu verfolgende Parameter können hier angegeben werden. PgBouncer weiß dann, dass sie im Variablencache des Clients verwaltet und auf dem Server wiederhergestellt werden sollen, sobald der Client aktiv wird.

Mehrere Werte werden als durch Kommas getrennte Liste angegeben (z. B. some_extension.setting, other_extension.setting).

Hinweis: Die meisten Parameter lassen sich auf diese Weise nicht vollständig verfolgen. PgBouncer erfährt nur bei Parametern, die Postgres an den Client meldet, von Änderungen durch SET. Postgres stellt eine offizielle Liste der an den Client gemeldeten Parameter bereit. Postgres-Erweiterungen können diese Liste jedoch ändern: Sie können eigene Parameter hinzufügen und melden sowie die Meldung bereits vorhandener Parameter veranlassen, die Postgres selbst nicht meldet. Insbesondere bewirkt Citus 12.0+, dass Postgres auch search_path meldet. Auch einige der standardmäßig verfolgten Parameter werden erst von neueren Postgres-Versionen gemeldet: default_transaction_read_only seit Postgres 14, scram_iterations seit Postgres 16 und search_path seit Postgres 18.

Bei einem verfolgten Parameter, den Postgres nicht meldet (z. B. search_path in Postgres-Versionen vor 18), kennt PgBouncer nur den Wert, den ein Client in seinem Startpaket (oder im Startparameter options) angegeben hat. Dieser Wert wird auf die Serververbindung angewendet, sobald der Client aktiv wird. Für Clients, die ihn nicht angegeben haben, wird der Parameter auf seinen Standardwert zurückgesetzt. Änderungen durch SET nach dem Verbindungsaufbau werden bei solchen Parametern nicht verfolgt und wirken sich daher auf andere Clients aus, die dieselbe Serververbindung nutzen, sofern nicht server_reset_query_always verwendet wird.

Das Postgres-Protokoll erlaubt Parametereinstellungen sowohl direkt als Parameter im Startpaket als auch innerhalb des Startpaketparameters options . track_extra_parameters unterstützt Parameter, die auf beide Arten angegeben werden. options selbst kann jedoch nicht in track_extra_parameters aufgenommen werden, sondern nur die in options enthaltenen Parameter.

Standard: leer

ignore_startup_parameters

Standardmäßig lässt PgBouncer in Startpaketen nur Parameter zu, die es verfolgen kann (die Liste steht unter track_extra_parameters). Alle anderen Parameter lösen einen Fehler aus. Weitere zulässige Parameter können hier angegeben werden. PgBouncer weiß dann, dass sie vom Administrator behandelt werden und ignoriert werden können.

Mehrere Werte werden als durch Kommas getrennte Liste angegeben (z. B. options,extra_float_digits).

Das Postgres-Protokoll erlaubt Parametereinstellungen sowohl direkt als Parameter im Startpaket als auch innerhalb des Startpaketparameters options . ignore_startup_parameters unterstützt Parameter, die auf beide Arten angegeben werden. Auch options selbst kann in ignore_startup_parameters aufgenommen werden; dann werden alle unbekannten Parameter innerhalb von options ignoriert.

Standard: leer

peer_id

Peer-ID, die diesen PgBouncer-Prozess innerhalb einer Gruppe miteinander verbundener PgBouncer-Prozesse identifiziert. Der Wert von peer_id sollte innerhalb einer solchen Gruppe eindeutig sein. Bei 0 ist PgBouncer-Peering deaktiviert. Weitere Informationen enthält die Dokumentation zum Abschnitt [peers]. Der Höchstwert für peer_id ist 16383.

Standard: 0

disable_pqexec

Deaktiviert das Protokoll Simple Query (PQexec). Anders als das Protokoll Extended Query erlaubt Simple Query mehrere Abfragen in einem Paket, was bestimmte Arten von SQL-Injection-Angriffen ermöglicht. Die Deaktivierung kann die Sicherheit erhöhen. Das bedeutet allerdings, dass nur Clients weiter funktionieren, die ausschließlich das Protokoll Extended Query verwenden.

Standard: 0

application_name_add_host

Fügt die Hostadresse und den Port des Clients zu dem Anwendungsnamen hinzu, der beim Verbindungsaufbau gesetzt wird. Dies hilft, die Herkunft problematischer Abfragen usw. zu ermitteln. Die Logik greift nur beim Verbindungsaufbau. Wird application_name später mit SET geändert, passt PgBouncer den Wert nicht erneut an.

Standard: 0

conffile

Zeigt den Pfad der aktuellen Konfigurationsdatei an. Wird er geändert, verwendet PgBouncer beim nächsten RELOAD / SIGHUP eine andere Konfigurationsdatei.

Standard: Datei aus der Befehlszeile

service_name

Wird bei der Registrierung eines win32-Dienstes verwendet.

Standard: pgbouncer

job_name

Alias für service_name.

stats_period

Legt fest, wie oft die in verschiedenen SHOW-Befehlen angezeigten Durchschnittswerte aktualisiert und wie oft aggregierte Statistiken ins Protokoll geschrieben werden (siehe jedoch log_stats). [Sekunden]

Standard: 60

max_prepared_statements

Bei einem Wert ungleich null verfolgt PgBouncer im Transaktions- und Statement-Pooling die vom Client gesendeten Befehle für benannte vorbereitete Anweisungen auf Protokollebene. PgBouncer stellt sicher, dass jede von einem Client vorbereitete Anweisung auf der zugehörigen Serververbindung verfügbar ist, auch wenn die Anweisung ursprünglich auf einer anderen Serververbindung vorbereitet wurde.

PgBouncer untersucht intern alle Abfragen, die Clients als vorbereitete Anweisung senden, und weist jeder eindeutigen Abfragezeichenfolge einen internen Namen im Format PGBOUNCER_{unique_id} zu. Wird dieselbe Abfragezeichenfolge mehrfach vorbereitet (möglicherweise von unterschiedlichen Clients), teilen sich diese Abfragen denselben internen Namen. PgBouncer bereitet die Anweisung auf dem eigentlichen PostgreSQL-Server ausschließlich unter dem internen Namen vor (also nicht unter dem vom Client angegebenen Namen). PgBouncer merkt sich den Namen, den der Client jeder vorbereiteten Anweisung gegeben hat. Vor der Weiterleitung an den Server schreibt es dann jeden Befehl, der eine vorbereitete Anweisung verwendet, um: Der clientseitige Name wird durch den internen Namen ersetzt (z. B. my_prepared_statement durch PGBOUNCER_123). Wichtiger noch: Ist die vom Client auszuführende Anweisung auf dem Server noch nicht vorbereitet (z. B. weil dem Client inzwischen ein anderer Server zugewiesen wurde als beim Vorbereiten), bereitet PgBouncer sie transparent vor der Ausführung vor.

Hinweis: Diese Nachverfolgung und Umschreibung von Befehlen für vorbereitete Anweisungen funktioniert nicht für entsprechende SQL-Befehle. PREPARE, EXECUTE und DEALLOCATE werden daher direkt an Postgres weitergeleitet. Ausgenommen sind die Befehle DEALLOCATE ALL und DISCARD ALL: Sie funktionieren wie erwartet und löschen die vorbereiteten Anweisungen, die PgBouncer für den Client verfolgt hat, der den Befehl sendet.

Der konkrete Wert dieser Einstellung steuert die Anzahl vorbereiteter Anweisungen, die in einem LRU-Cache auf einer einzelnen Serververbindung aktiv gehalten werden. Bei 0 ist die Unterstützung vorbereiteter Anweisungen für Transaktions- und Statement-Pooling deaktiviert. Für die beste Leistung sollte dieser Wert größer sein als die Anzahl der in der Anwendung häufig verwendeten vorbereiteten Anweisungen. Je höher der Wert, desto größer ist der Speicherbedarf jeder PgBouncer-Verbindung auf dem PostgreSQL-Server, da mehr Abfragen auf diesen Verbindungen vorbereitet bleiben. Auch der Speicherbedarf von PgBouncer selbst steigt, da es nun Abfragezeichenfolgen verwalten muss.

Die Auswirkungen auf den Speicherbedarf von PgBouncer sind jedoch nicht sehr groß:

• Jede eindeutige Abfrage wird einmal in einem globalen Abfragecache gespeichert.
• Jede Clientverbindung hält einen Puffer vor, mit dem Pakete umgeschrieben werden. Dieser ist höchstens 4-mal so groß wie pkt_buf. Diese Grenze wird allerdings oft nicht erreicht; sie tritt nur auf, wenn die Abfragen in den vorbereiteten Anweisungen zwischen 2- und 4-mal so groß wie pkt_buf sind.

Als Beispielszenario seien folgende Bedingungen angenommen:

• Es gibt 1000 aktive Clients.
• Die Clients bereiten 200 eindeutige Abfragen vor.
• Die durchschnittliche Größe einer Abfrage beträgt 5kB.
• Der Parameter pkt_buf ist auf den Standardwert 4096 (4kB) gesetzt.

Dann benötigt PgBouncer höchstens folgende Speichermenge für diese vorbereiteten Anweisungen:

200 x 5kB + 1000 x 4 x 4kB = ~17MB of memory.

Die Nachverfolgung vorbereiteter Anweisungen benötigt nicht nur Speicher, sondern erhöht auch die CPU-Auslastung, da PgBouncer die Abfragen untersuchen und umschreiben muss. Mehrere PgBouncer-Instanzen können am selben Port lauschen, um mehr als einen Prozessorkern für die Verarbeitung zu nutzen. Einzelheiten enthält die Dokumentation zur Option so_reuseport .

Vorbereitete Anweisungen bieten natürlich auch Leistungsvorteile. Wie bei einer direkten Verbindung zu PostgreSQL verringert das Vorbereiten einer häufig ausgeführten Abfrage den gesamten Aufwand für Parsing und Planung. Die Art, wie PgBouncer vorbereitete Anweisungen verfolgt, ist für die Leistung besonders vorteilhaft, wenn mehrere Clients dieselben Abfragen vorbereiten: Clientverbindungen verwenden eine vorbereitete Anweisung auf einer Serververbindung automatisch wieder, selbst wenn ein anderer Client sie vorbereitet hat. Bei einer pool_size von 20 und 100 Clients, die alle exakt dieselbe Abfrage vorbereiten, wird die Abfrage auf dem PostgreSQL-Server beispielsweise nur 20-mal vorbereitet (und damit geparst).

Die Wiederverwendung vorbereiteter Anweisungen hat einen Nachteil. Ändern sich die Rückgabe- oder Argumenttypen einer vorbereiteten Anweisung zwischen Ausführungen, gibt PostgreSQL derzeit einen Fehler wie den folgenden aus:

ERROR:  cached plan must not change result type

Solche Fehler lassen sich vermeiden, indem sichergestellt wird, dass mehrere Clients bei exakt derselben Abfragezeichenfolge in einer vorbereiteten Anweisung keine unterschiedlichen Argument- oder Ergebnistypen erwarten. Eine der häufigsten Situationen, in denen dieses Problem auftritt, ist eine DDL-Migration, bei der einer vorhandenen Tabelle eine Spalte hinzugefügt oder ein Spaltentyp geändert wird. In diesen Fällen kann nach der Migration RECONNECT in der PgBouncer-Administrationskonsole ausgeführt werden, um ein erneutes Vorbereiten der Abfrage zu erzwingen und den Fehler zu beheben.

Standard: 200

scram_iterations

Anzahl der Recheniterationen beim Hashen eines Passworts mit SCRAM-SHA-256. Eine höhere Iterationszahl schützt gespeicherte Passwörter zusätzlich vor Brute-Force-Angriffen, verlangsamt jedoch die Authentifizierung.

Standard: 4096

Authentifizierungseinstellungen

PgBouncer führt die Clientauthentifizierung selbst durch und hat eine eigene Benutzerdatenbank. Die folgenden Einstellungen steuern dieses Verhalten.

auth_type

Art der Benutzerauthentifizierung.

• cert: Der Client muss sich über TLS mit einem gültigen Clientzertifikat verbinden. Der Benutzername wird dann dem Feld CommonName des Zertifikats entnommen.
• md5: Verwendet eine MD5-basierte Passwortprüfung. Dies ist die Standardmethode zur Authentifizierung. auth_file kann sowohl MD5-gehashte Passwörter als auch Klartextpasswörter enthalten. Ist md5 konfiguriert und für einen Benutzer ein SCRAM-Secret hinterlegt, wird stattdessen automatisch SCRAM-Authentifizierung verwendet.
• scram-sha-256: Verwendet die Passwortprüfung mit SCRAM-SHA-256. auth_file muss SCRAM-Secrets oder Klartextpasswörter enthalten.
• plain: Das Passwort wird im Klartext über die Verbindung gesendet. Veraltet.
• trust: Es findet keine Authentifizierung statt. Der Benutzername muss dennoch in auth_file vorhanden sein.
• any: Wie die Methode trust, jedoch wird der angegebene Benutzername ignoriert. Alle Datenbanken müssen so konfiguriert sein, dass die Anmeldung als bestimmter Benutzer erfolgt. Außerdem erlaubt die Konsolendatenbank jedem Benutzer die Anmeldung als Statistikbenutzer; in admin_users aufgeführte Benutzer erhalten Administratorrechte.
• hba: Die tatsächliche Authentifizierungsmethode wird aus auth_hba_file geladen. Dies ermöglicht unterschiedliche Methoden für verschiedene Zugriffswege, etwa: Verbindungen über Unix-Sockets verwenden peer-Authentifizierung, Verbindungen über TCP müssen TLS verwenden.
• ldap: Benutzer werden wie in PostgreSQL über einen LDAP-Server authentifiziert (Einzelheiten unter https://www.postgresql.org/docs/current/auth-ldap.html ). Die LDAP-Verbindungsoptionen werden mit der Einstellung auth_ldap_options oder alternativ in auth_hba_file konfiguriert.
• pam: Verwendet PAM zur Benutzerauthentifizierung; auth_file wird ignoriert. Diese Methode ist nicht mit Datenbanken kompatibel, die die Option auth_user verwenden. Der an PAM gemeldete Dienstname lautet “pgbouncer”. pam wird in der HBA-Konfigurationsdatei nicht unterstützt.

auth_hba_file

HBA-Konfigurationsdatei, die verwendet wird, wenn auth_type auf hba gesetzt ist. Einzelheiten enthält der Abschnitt HBA-Dateiformat weiter unten.

Standard: nicht gesetzt

auth_ident_file

Datei mit Identitätszuordnungen, die verwendet wird, wenn auth_type auf hba gesetzt ist und eine Benutzerzuordnung definiert werden soll. Einzelheiten enthält der Abschnitt Format der Ident-Zuordnungsdatei weiter unten.

Standard: nicht gesetzt

auth_file

Name der Datei, aus der Benutzernamen und Passwörter geladen werden. Einzelheiten enthält der Abschnitt Format der Authentifizierungsdatei weiter unten.

Die meisten Authentifizierungsmethoden (siehe oben) erfordern, dass entweder auth_file oder auth_user gesetzt ist; andernfalls wären keine Benutzer definiert.

Standard: nicht gesetzt

auth_user

Ist auth_user gesetzt, wird jeder nicht in auth_file aufgeführte Benutzer mithilfe von auth_query unter Verwendung von auth_user aus pg_authid in der Datenbank abgefragt. Das Passwort für auth_user wird aus auth_file entnommen. (Benötigt auth_user kein Passwort, muss der Benutzer nicht in auth_file definiert sein.)

Der direkte Zugriff auf pg_authid erfordert Administratorrechte. Vorzuziehen ist stattdessen ein Benutzer ohne Superuser-Rechte, der eine SECURITY DEFINER-Funktion aufruft.

Standard: nicht gesetzt

auth_query

Abfrage zum Laden des Benutzerpassworts aus der Datenbank.

Der direkte Zugriff auf pg_authid erfordert Administratorrechte. Vorzuziehen ist stattdessen ein Benutzer ohne Superuser-Rechte, der eine SECURITY DEFINER-Funktion aufruft.

Die Abfrage wird in der Zieldatenbank ausgeführt. Wird eine Funktion verwendet, muss sie daher in jeder Datenbank installiert sein.

Die Abfrage muss zwei Spalten zurückgeben: den Benutzernamen und das Passwort (geeignet verschlüsselt/gehasht). Um einen nicht vorhandenen Benutzer zu melden, entweder keine Zeilen oder eine Zeile mit einem Nullwert für den Benutzer zurückgeben. (Die nachfolgende Standardabfrage gibt für einen nicht vorhandenen Benutzer keine Zeilen zurück. Die Variante mit dem Nullwert ist nützlich, wenn die Abfrage eine Funktion mit einem Datensatz als Rückgabewert aufruft, wie im Beispiel unter Beispiele weiter unten.) Ein Nullwert in der Passwortspalte bedeutet, dass der Benutzer existiert, aber kein Passwort für ihn verfügbar ist; somit wird kein vom Client angebotenes Passwort akzeptiert.

Standard: SELECT rolname, CASE WHEN rolvaliduntil < now() THEN NULL ELSE rolpassword END FROM pg_authid WHERE rolname=$1 AND rolcanlogin

auth_dbname

Name einer Datenbank im Abschnitt [databases], die für die Authentifizierung verwendet werden soll. Diese Option kann global gesetzt oder durch Angabe dieses Parameters in der Verbindungszeichenfolge überschrieben werden.

auth_ldap_options

LDAP-Verbindungsoptionen, die verwendet werden, wenn auth_type auf ldap gesetzt ist. (Wird nicht verwendet, wenn die Authentifizierung über auth_hba_file konfiguriert ist.) Beispiel:

auth_ldap_options = ldapurl="ldap://127.0.0.1:12345/dc=example,dc=net?uid?sub"

Protokollierungseinstellungen

syslog

Schaltet syslog ein oder aus. Unter Windows wird stattdessen das Ereignisprotokoll verwendet.

Standard: 0

syslog_ident

Name, unter dem Meldungen an syslog gesendet werden.

Standard: pgbouncer (Programmname)

syslog_facility

Facility, unter der Meldungen an syslog gesendet werden. Mögliche Werte: auth, authpriv, daemon, user, local0-7.

Standard: daemon

log_connections

Protokolliert erfolgreiche Anmeldungen.

Standard: 1

log_disconnections

Protokolliert Verbindungstrennungen mit Angabe des Grundes.

Standard: 1

log_pooler_errors

Protokolliert Fehlermeldungen, die der Pooler an Clients sendet.

Standard: 1

log_stats

Schreibt im Abstand von stats_period aggregierte Statistiken ins Protokoll. Kann deaktiviert werden, wenn externe Überwachungswerkzeuge dieselben Daten über SHOW-Befehle abrufen.

Standard: 1

verbose

Erhöht den Detailgrad der Ausgabe. Entspricht dem Schalter -v in der Befehlszeile. Beispielsweise entspricht -v -v in der Befehlszeile der Einstellung verbose=2. 3 ist der höchste derzeit unterstützte Detailgrad.

Standard: 0

Zugriffskontrolle für die Konsole

admin_users

Durch Kommas getrennte Liste von Datenbankbenutzern, die sich mit der Konsole verbinden und alle Befehle ausführen dürfen. Auch bei auth_type=any bestimmt diese Liste, wer Administratorrechte erhält; andere Benutzer können sich als Statistikbenutzer anmelden. Siehe die Prüfungen des Konsolenzugriffs in 1.26.0 .

Standard: leer

stats_users

Durch Kommas getrennte Liste von Datenbankbenutzern, die sich mit der Konsole verbinden und dort lesende Abfragen ausführen dürfen, also alle SHOW-Befehle.

Standard: leer

Verbindungsprüfungen und Zeitüberschreitungen

server_reset_query

Abfrage, die beim Freigeben einer Serververbindung an den Server gesendet wird, bevor die Verbindung anderen Clients zur Verfügung steht. Zu diesem Zeitpunkt läuft keine Transaktion; der Wert sollte daher weder ABORT noch ROLLBACK enthalten.

Die Abfrage soll alle Änderungen an der Datenbanksitzung bereinigen, damit der nächste Client die Verbindung in einem klar definierten Zustand erhält. Der Standardwert DISCARD ALL bereinigt alles, lässt dem nächsten Client jedoch keinen zuvor zwischengespeicherten Zustand. Eine weniger umfassende Abfrage ist möglich, z. B. DEALLOCATE ALL, um nur vorbereitete Anweisungen zu entfernen, sofern die Anwendung auch dann korrekt funktioniert, wenn Teile des Zustands erhalten bleiben.

Beim Transaktions-Pooling wird server_reset_query nicht verwendet, da Clients in diesem Modus keine sitzungsbezogenen Funktionen verwenden dürfen: Jede Transaktion läuft über eine andere Verbindung und erhält damit einen anderen Sitzungszustand.

Standard: DISCARD ALL

server_reset_query_always

Legt fest, ob server_reset_query in allen Pooling-Modi ausgeführt werden soll. Ist die Einstellung deaktiviert (Standard), wird server_reset_query nur in Pools mit Sitzungs-Pooling ausgeführt. Verbindungen im Transaktions-Pooling sollten keine Rücksetzabfrage benötigen.

Diese Einstellung dient als Behelf für fehlerhafte Konfigurationen, in denen Anwendungen sitzungsbezogene Funktionen über einen PgBouncer mit Transaktions-Pooling nutzen. Sie ersetzt nicht deterministische Fehler durch deterministische Fehler: Clients verlieren ihren Zustand immer nach jeder Transaktion.

Standard: 0

server_check_delay

Zeitraum, in dem freigegebene Verbindungen für die sofortige Wiederverwendung bereitgehalten werden, ohne server_check_query auf ihnen auszuführen. Bei 0 wird die Prüfung immer ausgeführt.

Standard: 30.0

server_check_query

Einfache Abfrage ohne Wirkung, mit der geprüft wird, ob die Serververbindung noch besteht.

Bei einer leeren Zeichenfolge ist die Verbindungsprüfung deaktiviert.

Bei <empty> wird eine leere Abfrage als Verbindungsprüfung gesendet.

Standard: <empty>

server_fast_close

Trennt eine Serververbindung im Sitzungs-Pooling sofort oder nach Abschluss der aktuellen Transaktion, wenn sie sich im Zustand “close_needed” befindet (gesetzt durch RECONNECT, ein RELOAD mit geänderten Verbindungseinstellungen oder eine DNS-Änderung), statt bis zum Ende der Sitzung zu warten. Im Statement- oder Transaktions-Pooling hat dies keine Wirkung, da es dort dem Standardverhalten entspricht.

Wird aufgrund dieser Einstellung eine Serververbindung vor Ende der Clientsitzung geschlossen, wird auch die Clientverbindung geschlossen. So bemerkt der Client, dass die Sitzung unterbrochen wurde.

Bei Sitzungs-Pooling mit lang laufenden Sitzungen lässt diese Einstellung Änderungen an der Verbindungskonfiguration schneller wirksam werden. Der Nachteil ist, dass Konfigurationsänderungen Clientsitzungen unterbrechen können; Clientanwendungen benötigen daher Logik zum erneuten Verbinden und Wiederherstellen des Sitzungszustands. Es gehen jedoch keine Transaktionen verloren, da laufende Transaktionen nicht unterbrochen werden, sondern nur inaktive Sitzungen.

Standard: 0

server_lifetime

Der Pooler schließt eine ungenutzte Serververbindung (die derzeit keiner Clientverbindung zugeordnet ist), wenn sie länger als diese Zeit besteht. Bei 0 wird die Verbindung nur einmal verwendet und dann geschlossen. [Sekunden]

Kann auch pro Datenbank im Abschnitt [databases] gesetzt werden.

Standard: 3600.0

server_idle_timeout

Ist eine Serververbindung länger als diese Anzahl von Sekunden inaktiv, wird sie geschlossen. Bei 0 ist diese Zeitüberschreitung deaktiviert. [Sekunden]

Standard: 600.0

server_connect_timeout

Werden Verbindungsaufbau und Anmeldung nicht innerhalb dieser Zeit abgeschlossen, wird die Verbindung geschlossen. [Sekunden]

Standard: 15.0

server_login_retry

Scheitert die Anmeldung am Server wegen eines Verbindungs- oder Authentifizierungsfehlers, wartet der Pooler diese Zeit, bevor er erneut versucht, sich zu verbinden. Während dieser Wartezeit erhalten neue Clients, die sich mit dem betroffenen Server verbinden wollen, sofort einen Fehler, ohne dass ein weiterer Verbindungsversuch erfolgt. [Sekunden]

Dieses Verhalten verhindert, dass Clients unnötig in einer Warteschlange auf eine verfügbare Serververbindung warten, wenn der Server nicht funktioniert. Es bedeutet jedoch auch, dass nach einer vorübergehenden Störung, etwa bei einem Neustart oder einer fehlerhaften Konfiguration, mindestens diese Zeit verstreicht, bevor der Pooler einen neuen Verbindungsversuch in Betracht zieht. Geplante Ereignisse wie Neustarts sollten normalerweise mit dem Befehl PAUSE gesteuert werden, um dies zu vermeiden.

Standard: 15.0

client_login_timeout

Baut ein Client eine Verbindung auf, meldet sich aber nicht innerhalb dieser Zeit erfolgreich an, wird seine Verbindung getrennt. [Sekunden]

Standard: 60.0

autodb_idle_timeout

Werden die automatisch (über *) erstellten Datenbankpools diese Anzahl von Sekunden nicht verwendet, werden sie freigegeben. Der Nachteil ist, dass dabei auch ihre Statistiken verloren gehen. [Sekunden]

Standard: 3600.0

pool_idle_timeout

Hat ein Pool (ein bestimmtes Datenbank/Benutzer-Paar) während dieser Anzahl von Sekunden weder Client- noch Serververbindungen, wird er freigegeben. Dies ähnelt autodb_idle_timeout, gibt jedoch einzelne Pools statt ganzer automatisch erstellter Datenbanken frei. Anders als server_idle_timeout (das inaktive Serververbindungen schließt, den Pool aber beibehält) gibt diese Einstellung den gesamten Pool frei, und zwar erst, wenn er vollständig leer ist.

Wie bei autodb_idle_timeout gehen dabei die Statistiken des freigegebenen Pools verloren. Da die datenbankbezogenen Gesamtwerte in SHOW STATS die Summe über die derzeit vorhandenen Pools darstellen, verringern sie sich beim Freigeben eines Pools. Überwachungssysteme können dies als Zurücksetzen eines Zählers fehlinterpretieren. Deshalb ist diese Einstellung standardmäßig deaktiviert. 0 deaktiviert sie. [Sekunden]

Standard: 0 (deaktiviert)

dns_max_ttl

Zeitraum, für den DNS-Abfragen zwischengespeichert werden können. Die tatsächliche DNS-TTL wird ignoriert. [Sekunden]

Standard: 15.0

dns_nxdomain_ttl

Zeitraum, für den DNS-Fehler und DNS-Abfragen mit NXDOMAIN zwischengespeichert werden können. [Sekunden]

Standard: 15.0

dns_zone_check_period

Intervall für die Prüfung, ob sich die Seriennummer einer Zone geändert hat.

PgBouncer kann DNS-Zonen aus Hostnamen ermitteln (alles nach dem ersten Punkt) und dann regelmäßig prüfen, ob sich die Seriennummer der Zone ändert. Erkennt es Änderungen, werden alle Hostnamen dieser Zone erneut aufgelöst. Ändert sich die IP-Adresse eines Hosts, werden dessen Verbindungen für ungültig erklärt.

Funktioniert nur mit dem c-ares-Backend (configure-Option --with-cares).

Standard: 0.0 (deaktiviert)

resolv_conf

Pfad einer eigenen resolv.conf-Datei. Damit lassen sich eigene DNS-Server und gegebenenfalls weitere Optionen zur Namensauflösung unabhängig von der globalen Betriebssystemkonfiguration angeben.

Erfordert das evdns-Backend (>= 2.0.3) oder das c-ares-Backend (>= 1.15.0).

Die Datei wird von der DNS-Backend-Bibliothek ausgewertet, nicht von PgBouncer. Einzelheiten zur zulässigen Syntax und zu den Direktiven stehen daher in der Dokumentation der Bibliothek.

Standard: leer (Betriebssystemvorgaben verwenden)

query_wait_notify

Zeit, die ein Client in der Warteschlange verbringt, bevor PgBouncer eine Benachrichtigung sendet, dass der Client in die Warteschlange eingereiht wird. [Sekunden]

Der Wert 0 deaktiviert diese Benachrichtigung.

Standard: 5

login_notify_message

Begrüßungsmeldung, die nach erfolgreicher Anmeldung an den Client gesendet wird. Damit kann sichergestellt werden, dass Clients erkennen, dass sie sich mit pgbouncer und nicht direkt mit postgres verbinden.

Standard: leer (keine Begrüßungsmeldung)

TLS-Einstellungen

Wird der Inhalt einer Zertifikats- oder Schlüsseldatei geändert, ohne den Dateinamen in der Konfiguration anzupassen, wird der neue Inhalt nach einem RELOAD für neue Verbindungen verwendet. Bestehende Verbindungen werden jedoch nicht geschlossen. Müssen aus Sicherheitsgründen alle Verbindungen so schnell wie möglich (ASAP) die neuen Dateien verwenden, empfiehlt sich ein RECONNECT nach dem RELOAD.

Jede Änderung einer TLS-Einstellung löst aus Sicherheitsgründen automatisch ein RECONNECT aus.

client_tls_sslmode

TLS-Modus für Verbindungen von Clients. TLS-Verbindungen sind standardmäßig deaktiviert. Bei Aktivierung müssen auch client_tls_key_file und client_tls_cert_file konfiguriert werden, um den Schlüssel und das Zertifikat festzulegen, mit denen PgBouncer Clientverbindungen annimmt. Das gebräuchlichste von PgBouncer unterstützte Zertifikatsdateiformat ist PEM.

• disable: Unverschlüsseltes TCP. Eine TLS-Anforderung des Clients wird ignoriert. Standard.
• allow: Fordert der Client TLS an, wird es verwendet. Andernfalls wird unverschlüsseltes TCP verwendet. Legt der Client ein Clientzertifikat vor, wird es nicht geprüft.
• prefer: Wie allow.
• require: Der Client muss TLS verwenden. Andernfalls wird die Clientverbindung abgelehnt. Legt der Client ein Clientzertifikat vor, wird es nicht geprüft.
• verify-ca: Der Client muss TLS mit einem gültigen Clientzertifikat verwenden.
• verify-full: Wie verify-ca.

client_tls_key_file

Privater Schlüssel, mit dem PgBouncer Clientverbindungen annimmt.

Standard: nicht gesetzt

client_tls_cert_file

Zertifikat für den privaten Schlüssel. Clients können es prüfen.

Standard: nicht gesetzt

client_tls_ca_file

Datei mit Stammzertifikaten zur Prüfung von Clientzertifikaten.

Standard: nicht gesetzt

client_tls_protocols

Zulässige TLS-Protokollversionen. Mögliche Werte: tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3. Kurzformen: all (tlsv1.0,tlsv1.1,tlsv1.2,tlsv1.3), secure (tlsv1.2,tlsv1.3).

Standard: secure

client_tls_ciphers

Zulässige TLS-Chiffren in OpenSSL-Syntax. Kurzformen:

• default/secure/fast/normal (alle verwenden die systemweiten OpenSSL-Vorgaben)
• all (aktiviert alle Chiffren, nicht empfohlen)

Betrifft nur Verbindungen mit TLS-Version 1.2 und niedriger. Für Version 1.3 siehe client_tls13_ciphers weiter unten.

Standard: default

client_tls13_ciphers

Zulässige Chiffren für TLS v1.3. Ist der Wert leer, wird der Wert von client_tls_ciphers verwendet. Mögliche Werte:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

Betrifft nur Verbindungen mit TLS-Version 1.3 und höher. Für Version 1.2 und niedriger siehe client_tls_ciphers.

Standard: <empty>

client_tls_ecdhcurve

Name der elliptischen Kurve für den ECDH-Schlüsselaustausch.

Mögliche Werte: none (DH ist deaktiviert), auto (256-Bit-ECDH), Kurvenname

Standard: auto

client_tls_dheparams

Art des DHE-Schlüsselaustauschs.

Mögliche Werte: none (DH ist deaktiviert), auto (2048-Bit-DH), legacy (1024-Bit-DH)

Standard: auto

server_tls_sslmode

TLS-Modus für Verbindungen zu PostgreSQL-Servern. Der Standardmodus ist prefer.

• disable: Unverschlüsseltes TCP. TLS wird beim Server gar nicht angefordert.
• allow: Verhält sich wie prefer: Zuerst wird TLS angefordert. Lehnt der Server TLS ab, wird auf unverschlüsseltes TCP zurückgegriffen. Das Serverzertifikat wird nicht geprüft.
• prefer: Bei PostgreSQL wird immer zuerst eine TLS-Verbindung angefordert. Wird sie abgelehnt, wird die Verbindung über unverschlüsseltes TCP aufgebaut. Das Serverzertifikat wird nicht geprüft. Standard.
• require: Die Verbindung muss TLS verwenden. Lehnt der Server dies ab, wird kein unverschlüsseltes TCP versucht. Das Serverzertifikat wird nicht geprüft.
• verify-ca: Die Verbindung muss TLS verwenden und das Serverzertifikat muss gemäß server_tls_ca_file gültig sein. Der Serverhostname wird nicht mit dem Zertifikat abgeglichen.
• verify-full: Die Verbindung muss TLS verwenden und das Serverzertifikat muss gemäß server_tls_ca_file gültig sein. Der Serverhostname muss mit den Zertifikatsangaben übereinstimmen.

server_tls_ca_file

Datei mit Stammzertifikaten zur Prüfung von PostgreSQL-Serverzertifikaten.

Standard: nicht gesetzt

server_tls_key_file

Privater Schlüssel, mit dem sich PgBouncer gegenüber dem PostgreSQL-Server authentifiziert.

Standard: nicht gesetzt

server_tls_cert_file

Zertifikat für den privaten Schlüssel. Der PostgreSQL-Server kann es prüfen.

Standard: nicht gesetzt

server_tls_protocols

Zulässige TLS-Protokollversionen. Mögliche Werte: tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3. Kurzformen: all (tlsv1.0,tlsv1.1,tlsv1.2,tlsv1.3), secure (tlsv1.2,tlsv1.3), legacy (all).

Standard: secure

server_tls_ciphers

Zulässige TLS-Chiffren in OpenSSL-Syntax. Kurzformen:

• default/secure/fast/normal (alle verwenden die systemweiten OpenSSL-Vorgaben)
• all (aktiviert alle Chiffren, nicht empfohlen)

Betrifft nur Verbindungen mit TLS-Version 1.2 und niedriger. Für Version 1.3 siehe server_tls13_ciphers weiter unten.

Standard: default

server_tls13_ciphers

Zulässige Chiffren für TLS v1.3. Ist der Wert leer, wird der Wert von server_tls_ciphers verwendet. Mögliche Werte:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256
• TLS_AES_128_CCM_SHA256

Betrifft nur Verbindungen mit TLS-Version 1.3 und höher. Für Version 1.2 und niedriger siehe server_tls_ciphers.

Standard: <empty>

Gefährliche Zeitüberschreitungen

Das Setzen der folgenden Zeitüberschreitungen kann unerwartete Fehler verursachen.

query_timeout

Abfragen, die länger als diese Zeit laufen, werden abgebrochen. Diese Einstellung sollte nur zusammen mit einem etwas kürzeren serverseitigen statement_timeout verwendet werden, damit sie nur bei Netzwerkproblemen greift. [Sekunden]

Standard: 0.0 (deaktiviert)

query_wait_timeout

Maximal zulässige Wartezeit von Abfragen auf ihre Ausführung. Wird die Abfrage innerhalb dieser Zeit keinem Server zugewiesen, wird die Clientverbindung getrennt. 0 deaktiviert diese Zeitüberschreitung. Bei Deaktivierung bleiben Clients unbegrenzt in der Warteschlange. [Sekunden]

Diese Einstellung verhindert, dass nicht reagierende Server Verbindungen blockieren. Sie hilft auch, wenn der Server ausgefallen ist oder Verbindungen aus irgendeinem Grund ablehnt.

Diese Einstellung kann auch pro Datenbank und pro Benutzer konfiguriert werden. Die Rangfolge lautet: Benutzer, dann Datenbank, dann global. Eine explizite 0 auf der ausgewählten Ebene deaktiviert diese Zeitüberschreitung. Siehe den Code zur Auswahl der Zeitüberschreitung in 1.26.0 .

Standard: 120.0

cancel_wait_timeout

Maximal zulässige Wartezeit von Abbruchanfragen auf ihre Ausführung. Wird die Abbruchanfrage innerhalb dieser Zeit keinem Server zugewiesen, wird die Clientverbindung getrennt. 0 deaktiviert diese Zeitüberschreitung. Bei Deaktivierung bleiben Abbruchanfragen unbegrenzt in der Warteschlange. [Sekunden]

Diese Einstellung verhindert, dass ein Client blockiert, wenn eine Abbruchanfrage wegen eines ausgefallenen Servers nicht weitergeleitet werden kann.

Standard: 10.0

client_idle_timeout

Clientverbindungen, die länger als diese Anzahl von Sekunden inaktiv sind, werden geschlossen. Dieser Wert sollte größer als die clientseitigen Einstellungen zur Verbindungslebensdauer sein und nur für Netzwerkprobleme verwendet werden. [Sekunden]

Standard: 0.0 (deaktiviert)

idle_transaction_timeout

Befindet sich ein Client länger als diese Zeit im Zustand “idle in transaction”, wird seine Verbindung getrennt. [Sekunden]

Standard: 0.0 (deaktiviert)

transaction_timeout

Befindet sich ein Client länger als diese Zeit im Zustand “in transaction”, wird seine Verbindung getrennt. [Sekunden]

Standard: 0.0 (deaktiviert)

Systemnahe Netzwerkeinstellungen

pkt_buf

Interne Puffergröße für Pakete. Beeinflusst die Größe der gesendeten TCP-Pakete und den allgemeinen Speicherbedarf. Tatsächliche libpq-Pakete können größer sein; der Wert muss daher nicht groß angesetzt werden.

Standard: 4096

max_packet_size

Maximale Größe von PostgreSQL-Paketen, die PgBouncer durchlässt. Ein Paket enthält entweder eine Abfrage oder eine Zeile einer Ergebnismenge. Die vollständige Ergebnismenge kann größer sein.

Standard: 2147483647

listen_backlog

Backlog-Argument für listen(2). Bestimmt, wie viele neue, noch nicht beantwortete Verbindungsversuche in der Warteschlange gehalten werden. Ist die Warteschlange voll, werden weitere neue Verbindungen verworfen.

Standard: 128

sbuf_loopcnt

Anzahl der Verarbeitungsschritte für Daten auf einer Verbindung, bevor zur nächsten übergegangen wird. Ohne diese Grenze kann eine Verbindung mit einer großen Ergebnismenge PgBouncer lange blockieren. Ein Durchlauf verarbeitet eine Datenmenge der Größe pkt_buf. 0 bedeutet keine Begrenzung.

Standard: 5

so_reuseport

Legt fest, ob die Socket-Option SO_REUSEPORT für lauschende TCP-Sockets gesetzt wird. Auf manchen Betriebssystemen ermöglicht dies, mehrere PgBouncer-Instanzen auf demselben Host am selben Port lauschen zu lassen, wobei der Kernel die Verbindungen automatisch verteilt. Mit dieser Option kann PgBouncer mehr CPU-Kerne nutzen. (PgBouncer arbeitet mit einem einzelnen Thread und verwendet einen CPU-Kern pro Instanz.)

Das genaue Verhalten hängt vom Betriebssystemkernel ab. Zum Zeitpunkt der Erstellung dieser Dokumentation hat die Einstellung auf (hinreichend aktuellen Versionen von) Linux, DragonFlyBSD und FreeBSD die gewünschte Wirkung. (Unter FreeBSD wird stattdessen die Socket-Option SO_REUSEPORT_LB angewendet.) Einige andere Betriebssysteme unterstützen die Socket-Option, ohne dass sie die gewünschte Wirkung hat: Mehrere Prozesse können sich an denselben Port binden, aber nur einer erhält die Verbindungen. Einzelheiten stehen in der Dokumentation zu setsockopt() des Betriebssystems.

Auf Systemen, die diese Socket-Option überhaupt nicht unterstützen, führt die Aktivierung dieser Einstellung zu einem Fehler.

Jede PgBouncer-Instanz auf demselben Host benötigt mindestens unterschiedliche Werte für unix_socket_dir und pidfile sowie für logfile, falls verwendet. Bei Nutzung dieser Option ist es außerdem nicht mehr möglich, sich über TCP/IP mit einer bestimmten PgBouncer-Instanz zu verbinden. Dies kann Auswirkungen auf die Überwachung und die Erfassung von Metriken haben.

Damit Abfrageabbrüche weiterhin funktionieren, sollte PgBouncer-Peering zwischen den verschiedenen PgBouncer-Prozessen eingerichtet werden. Einzelheiten stehen in der Dokumentation zur Konfigurationsoption peer_id und zum Konfigurationsabschnitt peers. Der Beispielabschnitt dieser Dokumentation enthält außerdem ein Beispiel mit Peering und so_reuseport.

Standard: 0

tcp_defer_accept

Setzt die Socket-Option TCP_DEFER_ACCEPT; Einzelheiten unter man 7 tcp. (Dies ist eine boolesche Option: 1 bedeutet aktiviert. Der bei Aktivierung tatsächlich gesetzte Wert ist derzeit fest auf 45 Sekunden codiert.)

Wird derzeit nur unter Linux unterstützt.

Standard: 1 unter Linux, sonst 0

tcp_socket_buffer

Standard: nicht gesetzt

tcp_keepalive

Aktiviert grundlegendes Keepalive mit den Betriebssystemvorgaben.

Unter Linux lauten die Systemvorgaben tcp_keepidle=7200, tcp_keepintvl=75, tcp_keepcnt=9. Auf anderen Betriebssystemen sind sie wahrscheinlich ähnlich.

Standard: 1

tcp_keepcnt

Standard: nicht gesetzt

tcp_keepidle

Standard: nicht gesetzt

tcp_keepintvl

Standard: nicht gesetzt

tcp_user_timeout

Setzt die Socket-Option TCP_USER_TIMEOUT. Sie gibt die maximale Zeit in Millisekunden an, während der gesendete Daten unbestätigt bleiben dürfen, bevor die TCP-Verbindung zwangsweise geschlossen wird. Bei 0 wird die Betriebssystemvorgabe verwendet.

Wird derzeit nur unter Linux unterstützt.

Standard: 0

Abschnitt [databases]

Der Abschnitt [databases] definiert die Namen der Datenbanken, mit denen sich PgBouncer-Clients verbinden können, und legt fest, wohin diese Verbindungen weitergeleitet werden. Der Abschnitt enthält Zeilen im Format key=value wie

dbname = connection string

Dabei wird der Schlüssel als Datenbankname und der Wert als Verbindungszeichenfolge interpretiert. Diese besteht aus key=value-Paaren mit den nachfolgend beschriebenen Verbindungsparametern (ähnlich wie bei libpq, allerdings wird libpq selbst nicht verwendet und der verfügbare Funktionsumfang unterscheidet sich). Beispiel:

foodb = host=host1.example.com port=5432
bardb = host=localhost dbname=bazdb

Der Datenbankname kann die Zeichen _0-9A-Za-z ohne Anführungszeichen enthalten. Namen mit anderen Zeichen müssen nach den üblichen SQL-Regeln für Bezeichner in doppelte Anführungszeichen gesetzt werden; ein einzelnes doppeltes Anführungszeichen wird dabei als "" geschrieben.

Der Datenbankname pgbouncer ist für die Administrationskonsole reserviert und kann hier nicht als Schlüssel verwendet werden.

* dient als Fallback-Datenbank: Existiert der genaue Name nicht, wird ihr Wert als Verbindungszeichenfolge für die angeforderte Datenbank verwendet. Gibt es beispielsweise den Eintrag (und keine anderen vorrangigen Einträge)

* = host=foo

verhält sich eine Verbindung zu PgBouncer mit Angabe der Datenbank bar effektiv so, als existiere der Eintrag

bar = host=foo dbname=bar

(da der Standardwert für dbname der clientseitige Datenbankname ist; siehe unten).

Solche automatisch erstellten Datenbankeinträge werden bereinigt, wenn sie länger als die durch autodb_idle_timeout festgelegte Zeit inaktiv bleiben.

dbname

Name der Zieldatenbank.

Standard: identisch mit dem clientseitigen Datenbanknamen

host

Hostname oder IP-Adresse des Verbindungsziels. Hostnamen werden beim Verbindungsaufbau aufgelöst; das Ergebnis wird gemäß dem Parameter dns_max_ttl zwischengespeichert. Ändert sich die Auflösung eines Hostnamens, werden bestehende Serververbindungen bei ihrer Freigabe (entsprechend dem Pooling-Modus) automatisch geschlossen, und neue Serververbindungen verwenden sofort das neue Ergebnis. Liefert DNS mehrere Ergebnisse, werden sie im Round-Robin-Verfahren verwendet.

Beginnt der Wert mit /, wird ein Unix-Socket im Dateisystem-Namensraum verwendet. Beginnt er mit @, wird ein Unix-Socket im abstrakten Namensraum verwendet.

Eine durch Kommas getrennte Liste von Hostnamen oder Adressen ist möglich. In diesem Fall werden Verbindungen im Round-Robin-Verfahren aufgebaut. (Enthält eine Hostliste Hostnamen, die ihrerseits per DNS zu mehreren Adressen aufgelöst werden, arbeiten die Round-Robin-Verfahren unabhängig voneinander. Dieses Verhalten ist implementierungsabhängig und kann sich ändern.) In einer Liste müssen alle Hosts jederzeit verfügbar sein: Es gibt keine Mechanismen, um nicht erreichbare Hosts zu überspringen, nur verfügbare Hosts aus einer Liste auszuwählen oder Ähnliches. (Dies unterscheidet sich von der Bedeutung einer Hostliste in libpq.) Außerdem betrifft dies nur die Auswahl der Ziele neuer Verbindungen. Zur Zuweisung von Clients an bereits bestehende Serververbindungen siehe auch server_round_robin.

Beispiele:

host=localhost
host=127.0.0.1
host=2001:0db8:85a3:0000:0000:8a2e:0370:7334
host=/var/run/postgresql
host=192.168.0.1,192.168.0.2,192.168.0.3

Standard: nicht gesetzt, das heißt, es wird ein Unix-Socket verwendet

port

Standard: 5432

user

Ist user= gesetzt, werden alle Verbindungen zur Zieldatenbank unter dem angegebenen Benutzer hergestellt. Für diese Datenbank gibt es somit nur einen Pool.

Andernfalls meldet sich PgBouncer mit dem Benutzernamen des Clients an der Zieldatenbank an, sodass es pro Benutzer einen Pool gibt.

password

Ist hier kein Passwort angegeben, wird für den oben angegebenen Benutzer das Passwort aus auth_file verwendet. Dynamische Verfahren zur Passwortermittlung wie auth_query werden derzeit nicht unterstützt.

auth_user

Überschreibt die globale Einstellung auth_user, falls angegeben.

auth_query

Überschreibt die globale Einstellung auth_query, falls angegeben. Die gesamte SQL-Anweisung muss in einfache Anführungszeichen gesetzt werden.

auth_dbname

Überschreibt die globale Einstellung auth_dbname, falls angegeben.

pool_size

Legt die maximale Größe der Pools für diese Datenbank fest. Falls nicht gesetzt, wird default_pool_size verwendet.

min_pool_size

Legt die minimale Poolgröße für diese Datenbank fest. Falls nicht gesetzt, wird der globale Wert von min_pool_size verwendet.

Wird nur durchgesetzt, wenn mindestens eine der folgenden Bedingungen zutrifft:

• In diesem Eintrag im Abschnitt [databases] ist für den Schlüssel user ein Wert gesetzt (ein sogenannter erzwungener Benutzer).
• Mindestens ein Client ist mit dem Pool verbunden.

reserve_pool_size

Legt die Anzahl zusätzlicher Verbindungen für diese Datenbank fest. Falls nicht gesetzt, wird der globale Wert von reserve_pool_size verwendet. Aus Gründen der Abwärtskompatibilität ist reserve_pool ein Alias für diese Option.

connect_query

Abfrage, die nach dem Verbindungsaufbau ausgeführt wird, bevor ein Client die Verbindung verwenden darf. Fehler der Abfrage werden protokolliert, ansonsten jedoch ignoriert.

pool_mode

Legt den Pooling-Modus für diese Datenbank fest. Falls nicht gesetzt, wird der Standardwert von pool_mode verwendet.

query_wait_timeout

Maximal zulässige Wartezeit von Abfragen auf ihre Ausführung. 0 deaktiviert diese Zeitüberschreitung. Wird diese Einstellung weggelassen, wird der jeweils geltende Standardwert übernommen. [Sekunden]

Weitere Einzelheiten enthält die Beschreibung der globalen Einstellung query_wait_timeout.

Ein benutzerspezifischer Wert für query_wait_timeout überschreibt diese Datenbankeinstellung. Ist keiner von beiden gesetzt, wird der globale Wert von query_wait_timeout verwendet.

load_balance_hosts

Ist in host eine durch Kommas getrennte Liste angegeben, steuert load_balance_hosts, welcher Eintrag für eine neue Verbindung ausgewählt wird.

Hinweis: Diese Einstellung steuert derzeit nur die Lastverteilung bei mehreren Hosts in der Verbindungszeichenfolge, nicht jedoch bei einem einzelnen Host, dessen DNS-Eintrag auf mehrere IP-Adressen verweist. Diese Funktion fehlt noch; in einer zukünftigen Version könnte diese Einstellung daher beide Arten der Lastverteilung steuern.

• round-robin: Ein neuer Verbindungsversuch wählt den nächsten Hosteintrag in der Liste.
• disable: Neue Verbindungen verwenden weiterhin denselben Hosteintrag, bis eine Verbindung fehlschlägt. Danach wird der nächste Hosteintrag ausgewählt.

Es wird empfohlen, server_login_retry unter den Standardwert zu setzen, um bei mehreren verfügbaren Hosts schnelle Wiederholungsversuche zu ermöglichen.

Standard: round-robin

max_db_connections

Konfiguriert eine datenbankweite Höchstzahl von Serververbindungen (alle Pools innerhalb der Datenbank haben also zusammen höchstens diese Anzahl von Serververbindungen).

max_db_client_connections

Konfiguriert eine datenbankweite Höchstzahl von Clientverbindungen. Sollte zusammen mit max_client_conn verwendet werden, um die Anzahl der Verbindungen zu begrenzen, die PgBouncer annehmen darf.

server_lifetime

Konfiguriert server_lifetime pro Datenbank. Falls nicht gesetzt, verwendet die Datenbank den instanzweit konfigurierten Wert von server_lifetime.

client_encoding

Fordert einen bestimmten Wert für client_encoding vom Server an.

datestyle

Fordert einen bestimmten Wert für datestyle vom Server an.

timezone

Fordert einen bestimmten Wert für timezone vom Server an.

Abschnitt [users]

Dieser Abschnitt enthält Zeilen im Format key=value wie

user1 = settings

Dabei wird der Schlüssel als Benutzername und der Wert als Liste von key=value-Paaren mit benutzerspezifischen Konfigurationseinstellungen interpretiert. Beispiel:

user1 = pool_mode=session

Hier sind nur wenige Einstellungen verfügbar.

Ist auth_file konfiguriert und ein Benutzer zwar in diesem Abschnitt definiert, aber nicht in auth_file aufgeführt, versucht PgBouncer bei gesetztem auth_user, mit auth_query ein Passwort für diesen Benutzer zu ermitteln. Ist auth_user nicht gesetzt, verhält sich PgBouncer so, als existiere der Benutzer, und gibt keine Meldungen “no such user” an den Client zurück; es akzeptiert jedoch auch kein angegebenes Passwort.

pool_size

Legt die maximale Poolgröße für alle Verbindungen dieses Benutzers fest. Falls nicht gesetzt, wird die Datenbankeinstellung oder default_pool_size verwendet.

reserve_pool_size

Legt die Anzahl zusätzlicher Verbindungen fest, die für einen Pool dieses Benutzers zugelassen werden. Falls nicht gesetzt, wird die Datenbankkonfiguration oder der globale Wert von reserve_pool_size verwendet.

pool_mode

Legt den Pooling-Modus für alle Verbindungen dieses Benutzers fest. Falls nicht gesetzt, wird die Datenbankeinstellung oder der Standardwert von pool_mode verwendet.

max_user_connections

Konfiguriert eine benutzerbezogene Höchstzahl von Serververbindungen (alle Pools dieses Benutzers haben also zusammen höchstens diese Anzahl von Serververbindungen).

query_timeout

Legt die maximale Laufzeit einer Benutzerabfrage in Sekunden fest. Falls gesetzt, überschreibt diese Zeitüberschreitung den oben beschriebenen serverweiten Wert von query_timeout.

query_wait_timeout

Maximal zulässige Wartezeit von Abfragen auf ihre Ausführung. 0 deaktiviert diese Zeitüberschreitung. Wird diese Einstellung weggelassen, wird der jeweils geltende Standardwert übernommen. [Sekunden]

Weitere Einzelheiten enthält die Beschreibung der globalen Einstellung query_wait_timeout.

Diese Einstellung überschreibt sowohl den datenbankspezifischen als auch den globalen Wert von query_wait_timeout. Falls nicht gesetzt, wird die Datenbankeinstellung verwendet; fehlt auch diese, gilt der globale Wert.

idle_transaction_timeout

Legt die maximale Zeit in Sekunden fest, während der ein Benutzer eine inaktive Transaktion offen halten kann. Falls gesetzt, überschreibt diese Zeitüberschreitung den oben beschriebenen serverweiten Wert von idle_transaction_timeout.

transaction_timeout

Legt die maximale Zeit in Sekunden fest, während der ein Benutzer eine Transaktion offen halten kann. Falls gesetzt, überschreibt diese Zeitüberschreitung den oben beschriebenen serverweiten Wert von transaction_timeout.

client_idle_timeout

Legt die maximale Zeit in Sekunden fest, während der ein Client untätig mit der PgBouncer-Instanz verbunden bleiben darf. Falls gesetzt, überschreibt diese Zeitüberschreitung den oben beschriebenen serverweiten Wert von client_idle_timeout.

Diese Zeitüberschreitung kann gefährlich sein.

max_user_client_connections

Konfiguriert eine benutzerbezogene Höchstzahl von Clientverbindungen. Dies ist das benutzerspezifische Gegenstück zur Einstellung max_client_conn.

Abschnitt [peers]

Der Abschnitt [peers] definiert die Peers, an die PgBouncer Abbruchanfragen weiterleiten kann, sowie die Ziele für diese Anfragen.

PgBouncer-Prozesse können durch einen Wert für peer_id und einen Abschnitt [peers] in der Konfiguration aller beteiligten PgBouncer-Prozesse zu einer Peer-Gruppe verbunden werden. Sie können Abbruchanfragen dann an den Prozess weiterleiten, der die abzubrechende Abfrage empfangen hat. Dies ist erforderlich, damit Abbrüche funktionieren, wenn mehrere PgBouncer-Prozesse (möglicherweise auf verschiedenen Servern) hinter demselben TCP-Load-Balancer stehen. Abbruchanfragen werden über andere TCP-Verbindungen gesendet als die abzubrechende Abfrage. Ein TCP-Load-Balancer kann die Verbindung einer Abbruchanfrage daher an einen anderen als den vorgesehenen Prozess senden. Durch das Peering erreichen diese Anfragen schließlich den richtigen Prozess. Eine ausführlichere Erklärung bietet diese Aufzeichnung eines Konferenzvortrags .

Der Abschnitt enthält Zeilen im Format key=value wie

peer_id = connection string

Dabei wird der Schlüssel als peer_id und der Wert als Verbindungszeichenfolge interpretiert. Diese besteht aus key=value-Paaren mit den nachfolgend beschriebenen Verbindungsparametern (ähnlich wie bei libpq, allerdings wird libpq selbst nicht verwendet und der verfügbare Funktionsumfang unterscheidet sich). Beispiel:

1 = host=host1.example.com
2 = host=/tmp/pgbouncer-2  port=5555

Hinweis 1: Damit Peering funktioniert, muss die peer_id jedes PgBouncer-Prozesses innerhalb der Peer-Gruppe eindeutig sein. Der Abschnitt [peers] sollte Einträge für jede dieser Peer-IDs enthalten. Ein Beispiel steht im Beispielabschnitt dieser Dokumentation. Der Abschnitt [peers] darf die peer_id des PgBouncer-Prozesses enthalten, für den die Konfiguration bestimmt ist, muss es aber nicht. Ein solcher Eintrag wird ignoriert, ist jedoch zur Vereinfachung der Konfigurationsverwaltung erlaubt: So kann in mehreren Konfigurationen exakt derselbe Abschnitt [peers] verwendet werden.

Hinweis 2: Peering zwischen unterschiedlichen Versionen wird unterstützt, solange alle Peers auf derselben Seite der Versionsgrenze v1.21.0 liegen. In v1.21.0 wurde die Codierung der Abbruch-Tokens so geändert, dass sie nicht mehr mit Tokens früherer Versionen kompatibel sind.

host

Hostname oder IP-Adresse des Verbindungsziels. Hostnamen werden beim Verbindungsaufbau aufgelöst; das Ergebnis wird gemäß dem Parameter dns_max_ttl zwischengespeichert. Liefert DNS mehrere Ergebnisse, werden sie im Round-Robin-Verfahren verwendet. Grundsätzlich wird jedoch von Hostnamen abgeraten, die zu mehreren IP-Adressen aufgelöst werden: Die Abbruchanfrage könnte dann weiterhin an den falschen Knoten weitergeleitet werden und müsste erneut weitergeleitet werden (was höchstens dreimal zulässig ist).

Beginnt der Wert mit /, wird ein Unix-Socket im Dateisystem-Namensraum verwendet. Beginnt er mit @, wird ein Unix-Socket im abstrakten Namensraum verwendet.

Beispiele:

host=localhost
host=127.0.0.1
host=2001:0db8:85a3:0000:0000:8a2e:0370:7334
host=/var/run/pgbouncer-1

port

Standard: 6432

pool_size

Legt die maximale Anzahl von Abbruchanfragen fest, die gleichzeitig zum Peer unterwegs sein können. Abbruchanfragen treffen häufig schubweise ein, etwa wenn der dahinterliegende Postgres-Server langsam oder ausgefallen ist. Deshalb ist es wichtig, pool_size nicht so niedrig zu setzen, dass diese Spitzen nicht bewältigt werden können.

Falls nicht gesetzt, wird default_pool_size verwendet.

Include-Direktive

Die PgBouncer-Konfigurationsdatei kann Include-Direktiven enthalten, die eine weitere einzulesende und zu verarbeitende Konfigurationsdatei angeben. So lässt sich die Konfiguration auf physisch getrennte Dateien aufteilen. Include-Direktiven haben folgende Form:

%include filename

Ist der Dateiname kein absoluter Pfad, wird er relativ zum aktuellen Arbeitsverzeichnis interpretiert.

Format der Authentifizierungsdatei

Dieser Abschnitt beschreibt das Format der mit auth_file angegebenen Datei. Es handelt sich um eine Textdatei im folgenden Format:

"username1" "password" ...
"username2" "md5abcdef012342345" ...
"username2" "SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>"

Es sollten mindestens 2 Felder vorhanden sein, die von doppelten Anführungszeichen umgeben sind. Das erste Feld ist der Benutzername; das zweite enthält ein Klartextpasswort, ein MD5-gehashtes Passwort oder ein SCRAM-Secret. PgBouncer ignoriert den Rest der Zeile. Doppelte Anführungszeichen in einem Feldwert können durch zwei aufeinanderfolgende doppelte Anführungszeichen maskiert werden.

PostgreSQL-Format für MD5-gehashte Passwörter:

"md5" + md5(password + username)

Der Benutzer admin mit dem Passwort 1234 hat somit das MD5-gehashte Passwort md545f2603610af569b6155c45067268c6b.

PostgreSQL-Format für SCRAM-Secrets:

SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>

Einzelheiten stehen in der PostgreSQL-Dokumentation und in RFC 5803.

Die in der Authentifizierungsdatei gespeicherten Passwörter oder Secrets dienen zwei Zwecken. Erstens werden sie zur Prüfung der Passwörter eingehender Clientverbindungen verwendet, wenn eine passwortbasierte Authentifizierungsmethode konfiguriert ist. Zweitens dienen sie als Passwörter für ausgehende Verbindungen zum Backend-Server, wenn dieser passwortbasierte Authentifizierung verlangt (sofern das Passwort nicht direkt in der Verbindungszeichenfolge der Datenbank angegeben ist).

Einschränkungen

Ist das Passwort im Klartext gespeichert, kann es für jede passwortbasierte Authentifizierung des Backend-Servers verwendet werden: Klartext, MD5 oder SCRAM (Einzelheiten unter https://www.postgresql.org/docs/current/auth-password.html ).

MD5-gehashte Passwörter können verwendet werden, wenn der Backend-Server MD5-Authentifizierung nutzt (oder einzelne Benutzer MD5-gehashte Passwörter haben).

SCRAM-Secrets können nur zur Anmeldung an einem Server verwendet werden, wenn auch die Clientauthentifizierung SCRAM nutzt, die PgBouncer-Datenbankdefinition keinen Benutzernamen angibt und die SCRAM-Secrets in PgBouncer und auf dem PostgreSQL-Server identisch sind (gleicher Salt und gleiche Iterationszahl, nicht nur dasselbe Passwort). Dies folgt aus einer grundlegenden Sicherheitseigenschaft von SCRAM: Aus dem gespeicherten SCRAM-Secret allein lassen sich keine Anmeldedaten ableiten.

Die Authentifizierungsdatei kann von Hand erstellt werden; sinnvoll ist auch die Erzeugung aus einer anderen Liste von Benutzern und Passwörtern. ./etc/mkauth.py enthält ein Beispielskript, das die Authentifizierungsdatei aus der Systemtabelle pg_authid erzeugt. Alternativ kann auth_query statt auth_file verwendet werden, um keine separate Authentifizierungsdatei pflegen zu müssen.

Hinweis zu verwalteten Servern

Ist der Backend-Server für SCRAM-Passwortauthentifizierung konfiguriert, kann sich PgBouncer nur erfolgreich authentifizieren, wenn es entweder a) das Benutzerpasswort im Klartext oder b) das zugehörige SCRAM-Secret kennt.

Einige Cloud-Anbieter (z. B. AWS RDS) verbieten den Zugriff auf sensible PostgreSQL-Systemtabellen zum Abrufen von Passwörtern. Selbst für den Benutzer mit den höchsten Rechten (z. B. ein Mitglied von rds_superuser) liefert select * from pg_authid die Meldung ERROR: permission denied for table pg_authid. Dies ist ein bekanntes Verhalten (Blogbeitrag ).

Ein bereits auf einem verwalteten Server gespeichertes SCRAM-Secret lässt sich daher nicht abrufen. Das erschwert die Konfiguration von PgBouncer mit demselben SCRAM-Secret. Mit dem folgenden Vorgehen kann dennoch auf beiden Seiten dasselbe SCRAM-Secret konfiguriert und verwendet werden:

Ein SCRAM-Secret für ein beliebiges Passwort mit einem Werkzeug erzeugen, das das Secret ausgeben kann. Beispielsweise gibt psql --echo-hidden mit dem Befehl \password das SCRAM-Secret in der Konsole aus, bevor es an den Server gesendet wird.

$ psql --echo-hidden <connection_string>
postgres=# \password <role_name>
Enter new password for user "<role_name>":
Enter it again:
********* QUERY **********
ALTER USER <role_name> PASSWORD 'SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>'
**************************

Das SCRAM-Secret aus QUERY notieren und in der Datei userlist.txt von PgBouncer setzen.

Wurde ein anderes Werkzeug als psql --echo-hidden verwendet, muss das SCRAM-Secret auch auf dem Server gesetzt werden (dazu kann ALTER ROLE <role_name> PASSWORD '<scram_secret>' verwendet werden).

HBA-Dateiformat

Der Pfad der HBA-Datei wird mit auth_hba_file angegeben. Sie wird nur verwendet, wenn auth_type auf hba gesetzt ist.

Die Datei folgt dem Format der PostgreSQL-Datei pg_hba.conf (siehe https://www.postgresql.org/docs/current/auth-pg-hba-conf.html ).

• Unterstützte Datensatztypen: local, host, hostssl, hostnossl.
• Datenbankfeld: Unterstützt all, replication, sameuser, @file und mehrere Namen. Nicht unterstützt: samerole, samegroup.
• Benutzernamensfeld: Unterstützt all, @file und mehrere Namen. Nicht unterstützt: +groupname.
• Adressfeld: Unterstützt all, IPv4 und IPv6. Nicht unterstützt: samehost, samenet, DNS-Namen und Domainpräfixe.
• Feld für die Authentifizierungsmethode: Unterstützt nur die Methoden, die PgBouncers auth_type unterstützt, sowie peer und reject, jedoch nicht any und pam, die nur global funktionieren.
• Der Parameter zur Benutzernamenszuordnung (map=) wird unterstützt, wenn auth_type auf cert oder peer gesetzt ist.

Format der Ident-Zuordnungsdatei

Der Pfad der Ident-Zuordnungsdatei wird mit auth_ident_file angegeben. Sie wird nur geladen, wenn auth_type auf hba gesetzt ist.

Das Dateiformat ist eine vereinfachte Variante der PostgreSQL-Datei für Ident-Zuordnungen (siehe https://www.postgresql.org/docs/current/auth-username-maps.html ).

• Es werden nur Zeilen der Form map-name system-username database-username unterstützt.
• Das Einbinden von Dateien/Verzeichnissen wird nicht unterstützt.
• Feld System-username: Nicht unterstützt: reguläre Ausdrücke.
• Feld Database-username: Unterstützt all oder einen einzelnen Postgres-Benutzernamen. Nicht unterstützt: +groupname und reguläre Ausdrücke.

Beispiele

Kleines Konfigurationsbeispiel:

[databases]
template1 = host=localhost dbname=template1 auth_user=someuser

[pgbouncer]
pool_mode = session
listen_port = 6432
listen_addr = localhost
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser
stats_users = stat_collector

Datenbankbeispiele:

[databases]

; foodb over Unix socket
foodb =

; redirect bardb to bazdb on localhost
bardb = host=localhost dbname=bazdb

; access to destination database will go with single user
forcedb = host=localhost port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISO

Beispiel einer sicheren Funktion für auth_query:

CREATE OR REPLACE FUNCTION pgbouncer.user_lookup(in i_username text, out uname text, out phash text)
RETURNS record AS $$
BEGIN
    SELECT rolname, CASE WHEN rolvaliduntil < now() THEN NULL ELSE rolpassword END
    FROM pg_authid
    WHERE rolname=i_username AND rolcanlogin
    INTO uname, phash;
    RETURN;
END;
$$ LANGUAGE plpgsql
   SECURITY DEFINER
   -- Set a secure search_path: trusted schema(s), then 'pg_temp'.
   SET search_path = pg_catalog, pg_temp;
REVOKE ALL ON FUNCTION pgbouncer.user_lookup(text) FROM public, pgbouncer;
GRANT EXECUTE ON FUNCTION pgbouncer.user_lookup(text) TO pgbouncer;

Beispielkonfigurationen für 2 per Peering verbundene PgBouncer-Prozesse, die mit so_reuseport mehrere Prozessorkerne nutzen. Die Konfiguration des ersten Prozesses:

[databases]
postgres = host=localhost dbname=postgres

[peers]
1 = host=/tmp/pgbouncer1
2 = host=/tmp/pgbouncer2

[pgbouncer]
listen_addr=127.0.0.1
auth_file=auth_file.conf
so_reuseport=1
unix_socket_dir=/tmp/pgbouncer1
peer_id=1

Die Konfiguration des zweiten Prozesses:

[databases]
postgres = host=localhost dbname=postgres

[peers]
1 = host=/tmp/pgbouncer1
2 = host=/tmp/pgbouncer2

[pgbouncer]
listen_addr=127.0.0.1
auth_file=auth_file.conf
so_reuseport=1
; only unix_socket_dir and peer_id are different
unix_socket_dir=/tmp/pgbouncer2
peer_id=2

Siehe auch

pgbouncer(1) - Handbuchseite zur allgemeinen Verwendung und zu Konsolenbefehlen

https://www.pgbouncer.org/

3 - Verwendung: pgbouncer-Befehl

Zusammenfassung

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

Unter Windows stehen folgende Optionen zur Verfügung:

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

Zusätzliche Optionen zur Einrichtung eines Windows-Dienstes:

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

Beschreibung

pgbouncer ist ein PostgreSQL-Verbindungspooler. Jede Zielanwendung kann sich mit pgbouncer verbinden, als wäre PgBouncer ein PostgreSQL-Server. pgbouncer stellt dann eine Verbindung zum tatsächlichen Server her oder verwendet eine bereits vorhandene Verbindung wieder.

Das Ziel von pgbouncer ist es, die Auswirkungen auf die Leistung beim Öffnen neuer Verbindungen zu PostgreSQL zu reduzieren.

Um die Transaktionssemantik beim Pooling von Verbindungen nicht zu beeinträchtigen, unterstützt pgbouncer beim Wechsel der Verbindungen mehrere Pooling-Varianten:

Sitzungs-Pooling

Die am wenigsten restriktive Methode. Sobald ein Client eine Verbindung herstellt, wird ihm für die gesamte Verbindungsdauer eine Serververbindung zugewiesen. Trennt der Client die Verbindung, wird die Serververbindung wieder in den Pool zurückgegeben. Dies ist die Standardmethode.

Transaktions-Pooling

Eine Serververbindung wird einem Client nur für die Dauer einer Transaktion zugewiesen. Sobald PgBouncer erkennt, dass die Transaktion beendet ist, wird die Serververbindung wieder in den Pool zurückgegeben.

Statement-Pooling

Die restriktivste Methode. Die Serververbindung wird unmittelbar nach Abschluss einer Abfrage in den Pool zurückgegeben. Transaktionen mit mehreren Anweisungen sind in diesem Modus nicht zulässig, da sie sonst nicht funktionieren würden.

Die Administrationsoberfläche von pgbouncer umfasst einige zusätzliche SHOW-Befehle. Sie stehen bei einer Verbindung mit der speziellen „virtuellen“ Datenbank pgbouncer zur Verfügung.

Seit Version 1.26.0 sendet PgBouncer bei der Anmeldung die ParameterStatus-Werte pgbouncer.version, pgbouncer.pool_mode und pgbouncer.max_prepared_statements an Clients. Treiber können anhand dieser Werte PgBouncer erkennen und ihr Verhalten anpassen. Die optionale Einstellung login_notify_message sendet nach erfolgreicher Anmeldung eine Begrüßungsmeldung vom Typ NOTICE.

Schnellstart

Die grundlegende Einrichtung und Verwendung erfolgen wie folgt:

1. Erstellen Sie eine Datei namens pgbouncer.ini. Weitere Informationen finden Sie in pgbouncer(5). Ein einfaches Beispiel:

    [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
   

2. Erstellen Sie eine Datei mit dem Namen userlist.txt, die die Benutzer enthält, die sich anmelden dürfen:

    "someuser" "same_password_as_in_server"
   

3. Starten Sie pgbouncer:

    $ pgbouncer -d pgbouncer.ini
   

4. Lassen Sie Ihre Anwendung (oder den psql-Client) eine Verbindung mit pgbouncer statt direkt mit dem PostgreSQL-Server herstellen:

    $ psql -p 6432 -U someuser template1
   

5. Verwalten Sie pgbouncer, indem Sie sich mit der speziellen Administrationsdatenbank pgbouncer verbinden und zunächst den Befehl SHOW HELP; ausführen:

    $ 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
      [...]
   

6. Wenn Sie pgbouncer.ini geändert haben, können Sie die Datei mit folgendem Befehl neu laden:

    pgbouncer=# RELOAD;
   

Befehlszeilenoptionen

-d, --daemon

Im Hintergrund ausführen. Ohne diese Option wird der Prozess im Vordergrund ausgeführt.

Im Daemon-Modus müssen sowohl pidfile als auch logfile oder syslog festgelegt sein. Nach dem Wechsel in den Hintergrund werden keine Protokollmeldungen mehr auf stderr ausgegeben.

Hinweis: Funktioniert nicht unter Windows; dort muss pgbouncer als Dienst ausgeführt werden.

-u USERNAME, --user= USERNAME

Beim Start zum angegebenen Benutzer wechseln.

-v, --verbose

Ausführlichkeit erhöhen. Kann mehrfach angegeben werden.

-q, --quiet

Keine Protokollausgabe auf stderr. Dies beeinflusst nicht die Ausführlichkeit der Protokollierung, sondern nur die Verwendung von stderr. Für den Einsatz in init.d-Skripten vorgesehen.

-V, --version

Version anzeigen.

-h, --help

Kurzhilfe anzeigen.

--regservice

Win32: PgBouncer als Windows-Dienst registrieren. Der Wert des Konfigurationsparameters service_name wird als Registrierungsname verwendet.

--unregservice

Win32: Registrierung des Windows-Dienstes aufheben.

Admin-Konsole

Die Konsole ist über eine normale Verbindung zur Datenbank pgbouncer erreichbar:

$ psql -p 6432 pgbouncer

Nur Benutzer, die in den Konfigurationsparametern admin_users oder stats_users aufgeführt sind, dürfen sich an der Konsole anmelden. (Bei auth_type=any ist dagegen jeder Benutzer als stats_user zugelassen.)

Zusätzlich darf sich der Benutzer pgbouncer ohne Passwort anmelden, sofern die Anmeldung über einen Unix-Socket erfolgt und der Client dieselbe Unix-Benutzer-ID (UID) wie der laufende Prozess besitzt.

Die Admin-Konsole unterstützt derzeit nur das einfache Abfrageprotokoll. Einige Treiber verwenden für alle Befehle das erweiterte Abfrageprotokoll und können daher nicht mit der Admin-Konsole verwendet werden.

Anzeigebefehle

Die SHOW-Befehle geben Informationen aus. Jeder Befehl wird nachfolgend beschrieben.

SHOW STATS

Zeigt Statistiken an. Die Gesamtwerte in diesem und verwandten Befehlen beziehen sich auf den Zeitraum seit dem Prozessstart; die Durchschnittswerte werden nach jedem stats_period-Intervall aktualisiert.

database

Statistiken werden pro Datenbank angezeigt.

total_xact_count

Gesamtanzahl der von pgbouncer gepoolten SQL-Transaktionen.

total_query_count

Gesamtanzahl der von pgbouncer gepoolten SQL-Befehle.

total_server_assignment_count

Gesamtzahl der Zuweisungen eines Servers an einen Client.

total_received

Gesamtvolumen des von pgbouncer empfangenen Netzwerkverkehrs in Byte.

total_sent

Gesamtvolumen des von pgbouncer gesendeten Netzwerkverkehrs in Byte.

total_xact_time

Gesamtzahl der Mikrosekunden, die pgbouncer während einer Transaktion mit PostgreSQL verbunden war – entweder im Leerlauf innerhalb der Transaktion oder bei der Ausführung von Abfragen.

total_query_time

Gesamtzahl der Mikrosekunden, die pgbouncer aktiv mit PostgreSQL verbunden war und Abfragen ausführte.

total_wait_time

Gesamte Wartezeit der Clients auf einen Server in Mikrosekunden. Sie wird aktualisiert, wenn einer Clientverbindung eine Backendverbindung zugewiesen wird.

total_client_parse_count

Gesamtzahl der von Clients erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

total_server_parse_count

Gesamtzahl der von pgbouncer auf einem Server erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

total_bind_count

Gesamtzahl der vorbereiteten Anweisungen, die von Clients zur Ausführung bereitgestellt und von pgbouncer an PostgreSQL weitergeleitet wurden. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

total_client_login_count

Gesamtzahl erfolgreicher Clientanmeldungen.

avg_xact_count

Durchschnittliche Anzahl von Transaktionen pro Sekunde im letzten Statistikzeitraum.

avg_query_count

Durchschnittliche Anzahl von Abfragen pro Sekunde im letzten Statistikzeitraum.

avg_server_assignment_count

Durchschnittliche Anzahl der Zuweisungen eines Servers an einen Client pro Sekunde im letzten Statistikzeitraum.

avg_recv

Durchschnittlich pro Sekunde empfangene Byte (von Clients).

avg_sent

Durchschnittlich pro Sekunde gesendete Byte (an Clients).

avg_xact_time

Durchschnittliche Transaktionsdauer in Mikrosekunden.

avg_query_time

Durchschnittliche Abfragezeit in Mikrosekunden.

avg_wait_time

Wartezeit der Clients auf einen Server in Mikrosekunden (Durchschnitt der Wartezeiten für Clients, die während des aktuellen stats_period einem Backend zugewiesen wurden).

avg_client_parse_count

Durchschnittliche Zahl der von Clients pro Sekunde erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

avg_server_parse_count

Durchschnittliche Zahl der von pgbouncer pro Sekunde auf einem Server erstellten vorbereiteten Anweisungen. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

avg_bind_count

Durchschnittliche Zahl der vorbereiteten Anweisungen, die pro Sekunde von Clients zur Ausführung bereitgestellt und von pgbouncer an PostgreSQL weitergeleitet wurden. Nur bei der Nachverfolgung benannter vorbereiteter Anweisungen relevant, siehe max_prepared_statements.

avg_client_login_count

Durchschnittliche Anzahl erfolgreicher Clientanmeldungen pro Sekunde.

SHOW STATS_TOTALS

Zeigt die kumulierten Statistiken pro Datenbank, die den total_-Feldern von SHOW STATS entsprechen. Die ausgegebenen Spaltennamen tragen kein Präfix total_: Die Spalte total_query_count heißt hier beispielsweise query_count.

SHOW STATS_AVERAGES

Teilmenge von SHOW STATS mit den Durchschnittswerten (avg_).

SHOW TOTALS

Wie SHOW STATS, jedoch über alle Datenbanken aggregiert.

SHOW SERVERS

type

S für Server.

user

Benutzername, mit dem pgbouncer die Verbindung zum Server herstellt.

database

Datenbankname.

replication

Gibt an, ob die Serververbindung Replikation nutzt. Kann none, logical oder physical sein.

state

Zustand der PgBouncer-Serververbindung, einer der folgenden: active, idle, used, tested, new, active_cancel, being_canceled.

addr

IP-Adresse des PostgreSQL-Servers.

port

Port des PostgreSQL-Servers.

local_addr

Verbindungsstartadresse auf dem lokalen Computer.

local_port

Verbindungsstartport auf dem lokalen Computer.

connect_time

Zeitpunkt des Verbindungsaufbaus.

request_time

Zeitpunkt der letzten Anfrage.

wait

Nicht für Serververbindungen verwendet.

wait_us

Nicht für Serververbindungen verwendet.

close_needed

1, wenn die Verbindung so schnell wie möglich geschlossen wird, weil das Neuladen einer Konfigurationsdatei oder eine DNS-Aktualisierung die Verbindungsinformationen geändert hat oder RECONNECT ausgeführt wurde.

ptr

Adresse des internen Objekts für diese Verbindung.

link

Adresse der Clientverbindung, mit der der Server verknüpft ist.

remote_pid

PID des Backend-Serverprozesses. Wurde die Verbindung über einen Unix-Socket hergestellt und unterstützt das Betriebssystem das Abrufen von Prozess-ID-Informationen, ist dies die Betriebssystem-PID. Andernfalls wird der Wert aus dem vom Server gesendeten Abbruchpaket entnommen; bei einem PostgreSQL-Server sollte dies die PID sein, bei einer anderen PgBouncer-Instanz ist es eine Zufallszahl.

tls

Eine Zeichenkette mit TLS-Verbindungsinformationen oder leer, wenn TLS nicht verwendet wird.

application_name

Ein String, der den application_name auf der verknüpften Clientverbindung enthält, oder leer, wenn dieser nicht gesetzt ist oder keine verknüpfte Verbindung besteht.

prepared_statements

Die Anzahl der auf dem Server vorbereiteten Anweisungen. Diese Zahl ist durch die Einstellung max_prepared_statements begrenzt.

id

Eindeutige ID für den Server.

SHOW CLIENTS

type

C für Client.

user

Benutzername der Clientverbindung.

database

Datenbankname.

replication

Gibt an, ob die Clientverbindung Replikation nutzt. Kann none, logical oder physical sein.

state

Zustand der Clientverbindung, einer der Werte active (Clientverbindungen, die mit Serververbindungen verknüpft sind), idle (Clientverbindungen ohne ausstehende Abfragen), waiting, active_cancel_req oder waiting_cancel_req.

addr

IP-Adresse des Clients.

port

Quellport des Clients.

local_addr

Lokale Endadresse der Verbindung.

local_port

Lokaler Endport der Verbindung.

connect_time

Zeitstempel des Verbindungsaufbaus.

request_time

Zeitstempel der letzten Clientanfrage.

wait

Aktuelle Wartezeit in Sekunden.

wait_us

Mikrosekundenanteil der aktuellen Wartezeit.

close_needed

Nicht für Clients verwendet.

ptr

Adresse des internen Objekts für diese Verbindung.

link

Adresse der Serververbindung, der der Client zugeordnet ist.

remote_pid

Prozess-ID, falls der Client über einen Unix-Socket verbunden ist und das Betriebssystem die ID abrufen kann.

tls

Ein String mit TLS-Verbindungsinformationen oder leer, falls TLS nicht verwendet wird.

application_name

Ein String, der den application_name enthält, der vom Client für diese Verbindung festgelegt wurde, oder leer, falls kein solcher Wert gesetzt wurde.

prepared_statements

Anzahl der vom Client vorbereiteten Anweisungen.

id

Eindeutige ID für den Client.

SHOW POOLS

Für jede Kombination aus Datenbank und Benutzer wird ein neuer Pool-Eintrag erstellt.

database

Datenbankname.

user

Benutzername.

cl_active

Clientverbindungen, die entweder Serververbindungen zugeordnet sind oder sich im Leerlauf befinden, ohne dass Abfragen zur Verarbeitung anstehen.

cl_waiting

Clientverbindungen, die Abfragen gesendet, aber noch keine Serververbindung erhalten haben.

cl_active_cancel_req

Clientverbindungen, die Abfrageabbrüche an den Server weitergeleitet haben und auf dessen Antwort warten.

cl_waiting_cancel_req

Clientverbindungen, die noch keine Abbruchanfragen an den Server weitergeleitet haben.

sv_active

Serververbindungen, die mit einem Client verbunden sind.

sv_active_cancel

Serververbindungen, die derzeit eine Abbruchanfrage weiterleiten.

sv_being_canceled

Serververbindungen, die normalerweise in den Leerlauf wechseln könnten, damit jedoch warten, bis alle noch laufenden Anforderungen zum Abbruch einer Abfrage auf diesem Server abgeschlossen sind.

sv_idle

Serververbindungen, die ungenutzt sind und sofort für Clientanfragen verwendet werden können.

sv_used

Serververbindungen, die länger als server_check_delay inaktiv waren, sodass server_check_query ausgeführt werden muss, bevor sie erneut verwendet werden können.

sv_tested

Serververbindungen, die derzeit entweder server_reset_query oder server_check_query ausführen.

sv_login

Serververbindungen, die gerade angemeldet werden.

maxwait

Bisherige Wartezeit des ersten (ältesten) Clients in der Warteschlange in Sekunden. Steigt dieser Wert, verarbeitet der aktuelle Serverpool die Anfragen nicht schnell genug. Ursache kann ein überlasteter Server oder eine zu kleine pool_size-Einstellung sein.

maxwait_us

Mikrosekundenanteil der maximalen Wartezeit.

pool_mode

Der verwendete Pool-Modus.

load_balance_hosts

Die verwendete load_balance_hosts-Einstellung, wenn der Host des Pools eine kommagetrennte Liste enthält.

SHOW PEER_POOLS

Für jeden konfigurierten Peer wird ein neuer peer_pool-Eintrag erstellt.

peer_id

ID des konfigurierten Peer-Eintrags.

cl_active_cancel_req

Clientverbindungen, die Abfrageabbrüche an den Server weitergeleitet haben und auf dessen Antwort warten.

cl_waiting_cancel_req

Clientverbindungen, die Abbruchanfragen noch nicht an den Server weitergeleitet haben.

sv_active_cancel

Serververbindungen, die derzeit eine Abbruchanfrage weiterleiten.

sv_login

Serververbindungen, deren Anmeldung gerade läuft.

SHOW LISTS

Zeigt die folgenden internen Listen und ihre Elementanzahl an. Jede Liste steht in einer eigenen Zeile mit den Spalten list und items:

databases

Anzahl der Datenbanken.

users

Anzahl der Benutzer.

peers

Anzahl der konfigurierten Peers.

pools

Anzahl der Pools.

peer_pools

Anzahl der Peer-Pools.

free_clients

Anzahl freier Clients. Diese Clients sind getrennt, PgBouncer behält jedoch den für sie reservierten Speicher bei, um ihn für künftige Clients wiederzuverwenden und neue Speicherzuweisungen zu vermeiden.

used_clients

Anzahl genutzter Clients.

login_clients

Anzahl der Clients im login-Zustand.

free_servers

Anzahl freier Server. Diese Server sind getrennt, PgBouncer behält jedoch den für sie reservierten Speicher bei, um ihn für künftige Server wiederzuverwenden und neue Speicherzuweisungen zu vermeiden.

used_servers

Anzahl genutzter Server.

dns_names

Anzahl der DNS-Namen im Cache.

dns_zones

Anzahl der DNS-Zonen im Cache.

dns_queries

Anzahl der laufenden DNS-Abfragen.

dns_pending

Nicht verwendet.

SHOW USERS

name

Der Benutzername.

pool_size

Benutzerspezifische Überschreibung von pool_size oder eine leere Zeichenfolge, falls nicht gesetzt.

reserve_pool_size

Benutzerspezifische Überschreibung von reserve_pool_size oder eine leere Zeichenfolge, falls nicht gesetzt.

pool_mode

Benutzerspezifische Überschreibung von pool_mode oder NULL, falls nicht gesetzt.

max_user_connections

Benutzerspezifische Einstellung max_user_connections. Ist sie für diesen Benutzer nicht gesetzt, wird der Standardwert angezeigt.

current_connections

Aktuelle Anzahl der Serververbindungen, die dieser Benutzer zu allen Servern geöffnet hat.

max_user_client_connections

Benutzerspezifische Einstellung max_user_client_connections. Ist sie für diesen Benutzer nicht gesetzt, wird der Standardwert angezeigt.

current_client_connections

Aktuelle Anzahl der Clientverbindungen, die dieser Benutzer zu PgBouncer geöffnet hat.

SHOW DATABASES

name

Name des konfigurierten Datenbankeintrags.

host

Host, zu dem PgBouncer eine Verbindung herstellt.

port

Port, zu dem PgBouncer eine Verbindung herstellt.

database

Tatsächlicher Name der Datenbank, zu der PgBouncer eine Verbindung herstellt.

force_user

Ist ein Benutzer Teil der Verbindungszeichenfolge, wird für die Verbindung zwischen PgBouncer und PostgreSQL unabhängig vom Clientbenutzer dieser angegebene Benutzer erzwungen.

pool_size

Maximale Anzahl an Serververbindungen.

min_pool_size

Minimale Anzahl an Serververbindungen.

reserve_pool_size

Maximale Anzahl zusätzlicher Verbindungen für diese Datenbank.

server_lifetime

Maximale Lebensdauer einer Serververbindung für diese Datenbank.

pool_mode

Datenbankspezifische Überschreibung von pool_mode oder NULL, wenn stattdessen der Standardwert verwendet wird.

load_balance_hosts

Datenbankspezifische load_balance_hosts-Einstellung, falls der Host eine kommagetrennte Liste enthält.

max_connections

Maximale Anzahl zulässiger Serververbindungen für diese Datenbank, wie durch max_db_connections global oder pro Datenbank festgelegt.

current_connections

Aktuelle Anzahl der Serververbindungen für diese Datenbank.

max_client_connections

Maximale Anzahl zulässiger Clientverbindungen für diese Datenbank. Maßgeblich ist die datenbankspezifische Einstellung max_db_client_connections oder, falls nicht gesetzt, deren globaler Standardwert.

current_client_connections

Aktuelle Anzahl der Clientverbindungen für diese Datenbank.

paused

1, wenn diese Datenbank derzeit pausiert ist, sonst 0.

disabled

1, wenn diese Datenbank derzeit deaktiviert ist, sonst 0.

SHOW PEERS

peer_id

ID des konfigurierten Peer-Eintrags.

host

Host, zu dem PgBouncer eine Verbindung herstellt.

port

Port, zu dem PgBouncer eine Verbindung herstellt.

pool_size

Maximale Anzahl der Serververbindungen, die zu diesem Peer hergestellt werden können.

SHOW SOCKETS, SHOW ACTIVE_SOCKETS

Zeigt systemnahe Informationen über alle oder nur die aktiven Sockets an. Dazu gehören die unter SHOW CLIENTS und SHOW SERVERS angezeigten Informationen sowie weitere systemnahe Angaben.

SHOW CONFIG

Zeigt die aktuellen Konfigurationseinstellungen mit einer Einstellung pro Zeile und den folgenden Spalten:

key

Name der Konfigurationsvariable.

value

Konfigurationswert.

default

Standardwert der Konfiguration.

changeable

Gibt mit yes oder no an, ob die Variable zur Laufzeit geändert werden kann. Wenn no, kann die Variable nur beim Start geändert werden. Verwenden Sie SET, um eine Variable zur Laufzeit zu ändern.

SHOW MEM

Zeigt systemnahe Informationen über die aktuellen Größen verschiedener interner Speicherreservierungen an. Diese Angaben können sich ändern.

SHOW DNS_HOSTS

Zeigt Hostnamen im DNS-Cache an.

hostname

Hostname.

ttl

Sekunden bis zur nächsten Abfrage.

addrs

Kommagetrennte Liste von Adressen.

SHOW DNS_ZONES

Zeigt DNS-Zonen im Cache an.

zonename

Zonenname.

serial

Aktuelle Seriennummer.

count

Anzahl von Hostnamen, die dieser Zone zugeordnet sind.

SHOW VERSION

Zeigt die PgBouncer-Version als Zeichenkette an.

SHOW STATE

Zeigt die Zustandseinstellungen von PgBouncer an. Mögliche Zustände sind active und paused.

Befehle zur Prozesskontrolle

PAUSE [db]

PgBouncer versucht, alle Serververbindungen zu trennen. Jede Verbindung wird erst getrennt, nachdem sie entsprechend dem Pooling-Modus des Serverpools freigegeben wurde (beim Transaktions-Pooling muss die Transaktion abgeschlossen sein, beim Statement-Pooling die Anweisung und beim Sitzungs-Pooling muss der Client die Verbindung trennen). Der Befehl kehrt erst zurück, nachdem alle Serververbindungen getrennt wurden. Für Datenbankneustarts vorgesehen.

Wird ein Datenbankname angegeben, wird nur diese Datenbank pausiert.

Neue Clientverbindungen zu einer pausierten Datenbank warten, bis RESUME aufgerufen wird.

DISABLE db

Weist alle neuen Clientverbindungen zur angegebenen Datenbank ab.

ENABLE db

Ermöglicht nach einem vorherigen DISABLE-Befehl wieder neue Clientverbindungen.

RECONNECT [db]

Schließt jede offene Serververbindung für die angegebene Datenbank oder für alle Datenbanken, sobald sie entsprechend dem Pooling-Modus freigegeben wird, selbst wenn ihre Lebensdauer noch nicht abgelaufen ist. Neue Serververbindungen können sofort hergestellt werden und verbinden sich bei Bedarf gemäß den Einstellungen der Poolgröße.

Dieser Befehl ist nützlich, wenn sich die Einrichtung der Serververbindung geändert hat, etwa für einen schrittweisen Wechsel zu einem neuen Server. Er muss nicht ausgeführt werden, wenn die Verbindungszeichenfolge in pgbouncer.ini geändert und neu geladen wurde (siehe RELOAD) oder wenn sich die DNS-Auflösung geändert hat; in diesen Fällen wird ein gleichwertiger Befehl automatisch ausgeführt. Er ist nur erforderlich, wenn eine dem PgBouncer nachgelagerte Komponente die Verbindungen weiterleitet.

Nach Ausführung dieses Befehls kann es längere Zeit dauern, bis alle Serververbindungen zum neuen Ziel führen; einige können noch das alte Ziel verwenden. Dies ist voraussichtlich nur beim Umschalten von schreibgeschütztem Datenverkehr zwischen schreibgeschützten Replikaten oder zwischen Knoten einer Multimaster-Replikation sinnvoll. Müssen alle Verbindungen gleichzeitig umgeschaltet werden, wird stattdessen PAUSE empfohlen. Sollen Serververbindungen ohne Wartezeit geschlossen werden, etwa bei einem Notfall-Failover statt eines schrittweisen Switchovers, kommt auch KILL infrage.

KILL [db]

Trennt sofort alle Client- und Serververbindungen für die angegebene Datenbank oder für alle Datenbanken mit Ausnahme der Administrationsdatenbank.

Neue Clientverbindungen zu einer Datenbank, für die KILL ausgeführt wurde, warten, bis RESUME aufgerufen wird.

KILL_CLIENT id

Trennt sofort die angegebene Clientverbindung sowie alle Serververbindungen des betreffenden Clients. Der Client, dessen Verbindung getrennt werden soll, wird durch den id-Wert identifiziert, der mit dem Befehl SHOW CLIENTS ermittelt werden kann.

Ein Beispielbefehl sieht etwa so aus: KILL_CLIENT 1234.

RESUME [db]

Nimmt den Betrieb nach einem vorherigen KILL- oder PAUSE-Befehl wieder auf.

SHUTDOWN

Der PgBouncer-Prozess wird beendet.

SHUTDOWN WAIT_FOR_SERVERS

Nimmt keine neuen Verbindungen mehr an und fährt herunter, nachdem alle Serververbindungen freigegeben wurden. Dies entspricht im Wesentlichen der Ausführung von PAUSE und SHUTDOWN. Zusätzlich werden bereits während des Wartens auf PAUSE keine neuen Verbindungen mehr angenommen und Clients, die auf eine Serververbindung warten, sofort getrennt. Beachten Sie, dass Unix-Sockets während des Herunterfahrens geöffnet bleiben, aber nur Verbindungen zur PgBouncer-Administrationskonsole annehmen.

SHUTDOWN WAIT_FOR_CLIENTS

Nimmt keine neuen Verbindungen mehr an und beendet den Prozess, sobald alle vorhandenen Clients ihre Verbindung getrennt haben. Beachten Sie, dass Unix-Sockets während des Herunterfahrens geöffnet bleiben, aber nur Verbindungen zur PgBouncer-Administrationskonsole annehmen. Mit diesem Befehl lässt sich nach dem folgenden Verfahren ein rollierender Neustart zweier PgBouncer-Prozesse ohne Ausfallzeit durchführen:

1. Lassen Sie zwei oder mehr PgBouncer-Prozesse mit so_reuseport auf demselben Port laufen (Peering konfigurieren wird empfohlen, ist aber nicht erforderlich). Für einen Neustart ohne Ausfallzeit werden diese Prozesse nacheinander neu gestartet. So können die übrigen weiterhin Verbindungen annehmen, während jeweils ein Prozess neu startet.
2. Wählen Sie den zuerst neu zu startenden Prozess; nennen wir ihn A.
3. Führen Sie für Prozess A SHUTDOWN WAIT_FOR_CLIENTS aus (oder senden Sie ihm SIGTERM).
4. Veranlassen Sie alle Clients, ihre Verbindung neu herzustellen. Warten Sie dazu etwa, bis der clientseitige Pooler aufgrund seines server_idle_timeout (oder einer ähnlichen Konfiguration) Neuverbindungen auslöst. Wird kein clientseitiger Pooler verwendet, können stattdessen die Clients neu gestartet werden. Sobald alle Clients wieder verbunden sind, beendet sich Prozess A automatisch, da keine Clients mehr mit ihm verbunden sind.
5. Starten Sie Prozess A erneut.
6. Wiederholen Sie die Schritte 3, 4 und 5 nacheinander für jeden verbleibenden Prozess, bis alle Prozesse neu gestartet wurden.

RELOAD

Der PgBouncer-Prozess lädt seine Konfigurationsdateien neu und aktualisiert änderbare Einstellungen. Dazu gehören die Hauptkonfigurationsdatei sowie die Dateien, die durch die Einstellungen auth_file und auth_hba_file angegeben sind.

PgBouncer erkennt, wenn das Neuladen einer Konfigurationsdatei die Verbindungsparameter einer Datenbankdefinition ändert. Eine vorhandene Serververbindung zum alten Ziel wird bei ihrer nächsten Freigabe entsprechend dem Pooling-Modus geschlossen; neue Serververbindungen verwenden sofort die aktualisierten Verbindungsparameter.

WAIT_CLOSE [db]

Wartet, bis alle Serververbindungen der angegebenen Datenbank oder aller Datenbanken den Zustand “close_needed” verlassen haben (siehe SHOW SERVERS). Der Befehl kann nach RECONNECT oder RELOAD aufgerufen werden, um zu warten, bis die jeweilige Konfigurationsänderung vollständig aktiviert ist, beispielsweise in Switchover-Skripten.

Weitere Befehle

SET key = arg

Ändert eine Konfigurationseinstellung (siehe auch SHOW CONFIG). Zum Beispiel:

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

(Beachten Sie, dass dieser Befehl in der PgBouncer-Administrationskonsole ausgeführt wird und PgBouncer-Einstellungen setzt. Ein in einer anderen Datenbank ausgeführter SET-Befehl wird wie jeder andere SQL-Befehl an das PostgreSQL-Backend weitergeleitet.)

Signale

SIGHUP

Konfiguration neu laden. Entspricht dem Befehl RELOAD an der Konsole.

SIGTERM

Besonders sicheres Herunterfahren. Wartet, bis alle vorhandenen Clients ihre Verbindung getrennt haben, nimmt jedoch keine neuen Verbindungen an. Dies entspricht SHUTDOWN WAIT_FOR_CLIENTS an der Konsole. Wird dieses Signal empfangen, während bereits ein Herunterfahren läuft, wird statt des „besonders sicheren Herunterfahrens“ ein „sofortiges Herunterfahren“ ausgelöst. In PgBouncer-Versionen vor 1.23.0 löste dieses Signal ein „sofortiges Herunterfahren“ aus.

SIGINT

Sicheres Herunterfahren. Entspricht SHUTDOWN WAIT_FOR_SERVERS an der Konsole. Wird dieses Signal empfangen, während bereits ein Herunterfahren läuft, wird statt des „sicheren Herunterfahrens“ ein „sofortiges Herunterfahren“ ausgelöst.

SIGQUIT

Sofortiges Herunterfahren. Entspricht SHUTDOWN an der Konsole.

SIGUSR1

Entspricht PAUSE an der Konsole.

SIGUSR2

Entspricht RESUME an der Konsole.

Libevent-Einstellungen

Aus der Libevent-Dokumentation:

Es ist möglich, die Unterstützung für epoll, kqueue, devpoll, poll oder select zu deaktivieren, indem die Umgebungsvariable EVENT_NOEPOLL, EVENT_NOKQUEUE, EVENT_NODEVPOLL, EVENT_NOPOLL oder EVENT_NOSELECT jeweils gesetzt wird.

Durch Setzen der Umgebungsvariablen EVENT_SHOW_METHOD zeigt libevent die verwendete Kernel-Benachrichtigungsmethode an.

Siehe auch

pgbouncer(5) – Handbuchseite mit Beschreibungen der Konfigurationseinstellungen

https://www.pgbouncer.org/

4 - PgBouncer kompilieren und installieren

Kompilieren

PgBouncer kann entweder mit dem Autoconf-basierten Build-System oder mit dem neueren, noch experimentellen Build-System Meson kompiliert werden. Für produktive Builds und die Paketerstellung wird derzeit Autoconf empfohlen. Voraussichtlich wird Meson in einer künftigen Version zum Standard und Autoconf entfernt. Daher sind Tests des Meson-Builds und Berichte über Probleme sehr willkommen. Für das Kompilieren werden einige Komponenten benötigt:

• Libevent 2.0+
• pkg-config
• OpenSSL 1.0.1+ für TLS-Unterstützung
• ein C-Compiler mit C11-Unterstützung
• (optional) c-ares als Alternative zu evdns von Libevent
• (optional) LDAP-Bibliotheken
• (optional) PAM-Bibliotheken

Der Meson-Build benötigt zusätzlich Meson 0.58+ und Ninja , der Autoconf-Build GNU Make 3.81+.

Wenn alle Abhängigkeiten installiert sind, mit Autoconf kompilieren:

$ ./configure --prefix=/usr/local
$ make
$ make install

oder mit Meson (experimentell):

$ meson setup build --prefix=/usr/local
$ meson compile -C build
$ meson install -C build

Wenn Sie PgBouncer direkt aus dem Git-Repository oder für Windows kompilieren, beachten Sie die entsprechenden Anleitungen weiter unten.

Unterstützung für DNS-Abfragen

PgBouncer löst Hostnamen beim Verbindungsaufbau auf und nicht nur einmal beim Einlesen der Konfiguration. Dafür ist eine asynchrone DNS-Implementierung erforderlich. Die folgende Tabelle zeigt die unterstützten Backends und die Reihenfolge, in der sie geprüft werden:

1. EDNS0 ist erforderlich, wenn einem Hostnamen mehr als 8 Adressen zugeordnet sind.
2. Eine SOA-Abfrage ist erforderlich, um Hostnamen bei einer Änderung der Zonen-Seriennummer erneut zu prüfen.
3. Um EDNS0 zu aktivieren, fügen Sie options edns0 zu /etc/resolv.conf hinzu.

c-ares ist die Implementierung mit dem größten Funktionsumfang und wird für die meisten Einsatzbereiche sowie für die Erstellung von Binärpaketen empfohlen (sofern eine ausreichend neue Version verfügbar ist). Das in Libevent integrierte evdns eignet sich unter Beachtung der genannten Einschränkungen ebenfalls für viele Einsatzbereiche. Die übrigen Backends sind inzwischen weitgehend veraltet und werden kaum noch getestet.

Standardmäßig wird c-ares verwendet, sofern es gefunden wird. Der Einsatz lässt sich mit -Dcares=enabled (configure: --with-cares) erzwingen oder mit -Dcares=disabled (configure: --without-cares) deaktivieren. Wenn c-ares nicht verwendet wird (weil es nicht gefunden oder deaktiviert wurde), kommt Libevent zum Einsatz. Mit -Devdns=false (configure: --disable-evdns) wird evdns von Libevent deaktiviert und auf eine libc-basierte Implementierung zurückgegriffen.

Optionale Funktionen

Meson erkennt die Unterstützung für PAM, LDAP und systemd automatisch: Die Optionen -Dpam, -Dldap und -Dsystemd haben den Standardwert auto. Die jeweilige Funktion wird also eingebaut, wenn ihre Bibliotheken vorhanden sind. Mit -D<feature>=enabled lässt sich eine Funktion ausdrücklich aktivieren, mit -D<feature>=disabled deaktivieren. Der Autoconf-Build erkennt diese Funktionen nicht automatisch; sie müssen ausdrücklich mit --with-pam, --with-ldap oder --with-systemd aktiviert werden.

PAM-Authentifizierung

Nach dem Kompilieren mit PAM-Unterstützung steht der neue globale Authentifizierungstyp pam zur Verfügung, mit dem Benutzer über PAM authentifiziert werden können.

LDAP-Authentifizierung

Nach dem Kompilieren mit LDAP-Unterstützung steht der neue globale Authentifizierungstyp ldap zur Verfügung, mit dem Benutzer über LDAP authentifiziert werden können.

systemd-Integration

Die systemd-Unterstützung ermöglicht die Verwendung von Type=notify (oder Type=notify-reload mit systemd 253 oder neuer) sowie die Socket-Aktivierung. Beispiele finden sich in etc/pgbouncer.service und etc/pgbouncer.socket.

Aus dem Git-Repository kompilieren

Beim Autoconf-Build müssen die Header- und Konfigurationsdateien generiert werden, bevor configure ausgeführt werden kann:

$ git clone --branch pgbouncer_1_26_0 https://github.com/pgbouncer/pgbouncer.git
$ cd pgbouncer
$ ./autogen.sh
$ ./configure
$ make
$ make install

Standardmäßig werden alle Dateien unter /usr/local installiert. Sie können für configure eine oder mehrere Befehlszeilenoptionen angeben. Führen Sie ./configure --help aus, um die verfügbaren Optionen und die Umgebungsvariablen aufzulisten, mit denen sich die Konfiguration anpassen lässt.

Zusätzlich erforderliche Pakete für den Autoconf-Build aus Git: autoconf, automake, libtool, pandoc

Mit Meson lässt sich direkt aus einem Checkout kompilieren; zum Erstellen der Handbuchseiten wird pandoc benötigt:

$ meson setup build
$ meson compile -C build
$ meson install -C build

Mit meson configure build lassen sich die verfügbaren -D-Optionen auflisten.

Tests

Weitere Informationen zum Ausführen der Tests finden Sie in der Datei README.md im Testverzeichnis .

Kompilieren unter Windows

Die einzige unterstützte Build-Umgebung unter Windows ist MinGW. Cygwin und Visual $ANYTHING werden nicht unterstützt.

Zum Kompilieren unter MinGW den üblichen Autoconf-Build ausführen:

$ ./configure
$ make

oder den experimentellen Meson-Build:

$ meson setup build
$ meson compile -C build

Für eine Cross-Kompilierung von Unix aus mit Autoconf:

$ ./configure --host=i586-mingw32msvc

Die LDAP-Kompilierungsoption wird unter Windows derzeit nicht unterstützt.

Betrieb unter Windows

Der Aufruf über die Befehlszeile erfolgt wie üblich. Die Schalter -d (Daemon-Modus) und -u (Benutzerwechsel) funktionieren jedoch nicht.

Wenn Sie PgBouncer als Windows-Dienst ausführen möchten, legen Sie mit dem Parameter service_name einen Namen für den Dienst fest. Danach:

$ pgbouncer -regservice config.ini

Zum Deinstallieren des Dienstes:

$ pgbouncer -unregservice config.ini

Um das Windows-Ereignisprotokoll zu nutzen, setzen Sie syslog = 1 in der Konfigurationsdatei. Zuvor müssen Sie pgbevent.dll registrieren:

$ regsvr32 pgbevent.dll

Um die Registrierung aufzuheben, führen Sie folgenden Befehl aus:

$ regsvr32 /u pgbevent.dll

5 - Quellcode-Releases zum Download

PgBouncer 1.26

PgBouncer 1.25

PgBouncer 1.24

PgBouncer 1.23

PgBouncer 1.22

PgBouncer 1.21

PgBouncer 1.20

PgBouncer 1.19

PgBouncer 1.18

PgBouncer 1.17

PgBouncer 1.16

PgBouncer 1.15

PgBouncer 1.14

PgBouncer 1.13

PgBouncer 1.12

PgBouncer 1.11

PgBouncer 1.10

PgBouncer 1.9

PgBouncer 1.8

PgBouncer 1.7

PgBouncer 1.6

PgBouncer 1.5

PgBouncer 1.4

PgBouncer 1.3

PgBouncer 1.2

PgBouncer 1.1

PgBouncer 1.0

Binärpakete

Viele Betriebssystemdistributionen stellen ein eigenes natives PgBouncer-Paket beziehungsweise einen Port bereit. Daher kann es sinnvoll sein, zunächst zu prüfen, ob PgBouncer bereits für Ihr Betriebssystem verfügbar ist.

In den folgenden dedizierten Paketquellen sind unter Umständen neuere Versionen verfügbar als in den Repositories der jeweiligen Distribution:

• RPM: yum.postgresql.org
• Deb: apt.postgresql.org

6 - Änderungsprotokoll

PgBouncer 1.26.x

2026-09-23 - PgBouncer 1.26.0 - „Alle bisherigen search_path ignorieren“

• Sicherheit
  • CVE-2026-19888 behoben: PgBouncer vor 1.26.0 prüfte nicht, ob die SCRAM-Nachricht client-final-message eine Nonce enthielt. Ein nicht authentifizierter Angreifer konnte PgBouncer aus der Ferne zum Absturz bringen, indem er eine client-final-message ohne Nonce sendete. Dies gilt auch für nicht existierende Benutzer, da PgBouncer für diese einen SCRAM-Austausch simuliert. Dieser Fehler bestand seit der Einführung der SCRAM-Unterstützung in PgBouncer 1.11.0.
  • CVE-2026-6668 behoben: Ein Ganzzahlüberlauf in der Logik zur Vergrößerung des Paketpuffers konnte PgBouncer vor 1.26.0 in einer Endlosschleife hängen lassen. Dazu musste eine große Datenmenge in einen einzelnen Paketpuffer gesendet werden. Dies ist ohne vorherige Authentifizierung möglich, wenn max_packet_size seinen Standardwert behält. Da PgBouncer nur einen Thread verwendet, konnte es bis zum Beenden des Prozesses keine Clients mehr bedienen.
  • CVE-2026-6669 behoben: PgBouncer vor 1.26.0 begrenzte die von einem Server akzeptierte SCRAM-Iterationszahl nicht. Ein böswilliger oder kompromittierter PostgreSQL-Server konnte PgBouncer dadurch bei einer einzigen Anmeldung zu unbegrenzt viel Rechenarbeit veranlassen. Währenddessen konnte PgBouncer keine anderen Clients und Datenbanken bedienen. Die Iterationszahl darf jetzt höchstens 1000000 betragen.
• Funktionen
  • Alle Parameter, die PostgreSQL standardmäßig meldet, werden nachverfolgt. Insbesondere werden damit search_path (ab PostgreSQL 18) und default_transaction_read_only (ab PostgreSQL 14) jetzt standardmäßig nachverfolgt. Bisher beeinflusste ein Client, der im Transaktions-Pooling-Modus SET search_path oder SET default_transaction_read_only = true ausführte, andere Clients, die später dieselbe Serververbindung verwendeten. (#1580 , #1573 )
  • Die Einstellung pool_idle_timeout zum Entfernen längere Zeit ungenutzter Pools hinzugefügt. Dies ist bei Konfigurationen mit vielen verschiedenen Benutzern nützlich, die sich selten verbinden. Ohne diese Einstellung wächst die Anzahl der Pools in solchen Konfigurationen unbegrenzt. Die Einstellung ist standardmäßig deaktiviert, da beim Entfernen eines Pools auch dessen Statistiken verloren gehen. (#1491 )
  • query_wait_timeout kann pro Benutzer und pro Datenbank konfiguriert werden. (#1449 )
  • Die Statistik client_login_count zu SHOW STATS hinzugefügt. Sie zählt erfolgreiche Client-Anmeldungen und ermöglicht es, Clients zu erkennen, die ständig Verbindungen auf- und abbauen. (#1457 )
  • Bei der Anmeldung werden PgBouncer-spezifische ParameterStatus-Nachrichten an Clients gesendet: pgbouncer.version, pgbouncer.pool_mode und pgbouncer.max_prepared_statements. Damit können Clients und Treiber erkennen, dass sie über PgBouncer verbunden sind, und ihr Verhalten entsprechend anpassen. (#1490 )
  • Die Einstellung login_notify_message hinzugefügt. Ist sie gesetzt, wird ihr Wert nach der Anmeldung als NOTICE-Nachricht an Clients gesendet. Damit lässt sich Clients deutlich machen, dass sie über PgBouncer und nicht direkt mit PostgreSQL verbunden sind. (#1488 )
  • Unterstützung für das Bauen von PgBouncer mit meson hinzugefügt, einschließlich eines Windows-Builds mit der UCRT64-Umgebung. Builds mit Autoconf werden weiterhin unterstützt. (#1524 , #1426 , #1568 , #1585 , #1602 , #1607 )
  • Ein Logo hinzugefügt. (#1609 )
• Änderungen
  • Die veraltete Funktion für Online-Neustarts (-R, auch als Übernahme bezeichnet) entfernt, zusammen mit den Verwaltungsbefehlen SHOW FDS und SUSPEND, die nur zu ihrer Unterstützung vorhanden waren. Verwenden Sie stattdessen rollierende Neustarts mit so_reuseport . (#1581 )
  • Die maximale Passwortlänge auf 65535 Bytes erhöht, entsprechend libpq. (#1310 , #1520 )
  • Ein von auth_query zurückgegebener Benutzername NULL wird genauso behandelt wie ein Ergebnis ohne Zeilen und nicht mehr als Fehler. (#1569 )
  • SET extra_float_digits wird in der Verwaltungsdatenbank akzeptiert. Neuere PostgreSQL-JDBC-Treiber senden diesen Befehl beim Verbindungsaufbau. (#1550 )
  • mkauth.py kann durch Angabe von - als Ausgabedatei nach stdout schreiben. (#1514 )
  • Bei Builds mit OpenSSL 3 werden bei einem unerwarteten EOF von Clients keine störenden Fehlermeldungen mehr protokolliert. (#1507 )
  • Bei Builds mit OpenSSL 3 enthalten TLS-Fehlermeldungen den zugrunde liegenden Systemfehler. (#1492 )
  • Ein C11-Compiler ist erforderlich. (#1417 )
  • Es wird protokolliert, welches Limit das Verdrängen einer Serververbindung ausgelöst hat. Der Trennungsgrund lautet jetzt evicted for max_db_connections, evicted for pool_size oder evicted for max_user_connections statt lediglich evicted. (#1597 )
• Fehlerbehebungen
  • Behoben, dass verspätete COPY-Nachrichten im Transaktions-Pooling-Modus den Pool erschöpften. Dadurch funktioniert COPY in diesem Modus auch außerhalb einer expliziten Transaktion. (#1471 )
  • Fehler bei der LDAP-Authentifizierung mit langen DNs durch Erhöhen der maximalen Länge von LDAP-URLs behoben. (#1497 )
  • Behoben, dass die SCRAM-Durchleitung zwischengespeicherte Anmeldedaten eines erzwungenen Benutzers beschädigte. Dadurch schlugen Serveranmeldungen fehl, weil der eigentliche Server den SCRAM-Nachweis zurückwies. (#1612 )
  • Behoben, dass die SCRAM-Durchleitung mit gespeicherten SCRAM-Secrets nach dem erneuten Verbindungsaufbau zum Server mit dem Fehler “password is SCRAM secret but client authentication did not provide SCRAM keys” fehlschlug. (#1504 , Fehler in 1.25.1 eingeführt)
  • Einen Absturz durch Zugriff auf bereits freigegebenen Speicher behoben, wenn ein Replikationsclient die Verbindung trennt, während die Anmeldung seiner Serververbindung noch läuft. (#1577 )
  • Das Verdrängen ungenutzter Serververbindungen für Replikationsclients bei vollem Pool korrigiert. Bisher konnte ein einzelner Replikationsclient alle ungenutzten Server im Pool statt nur eines verdrängen. Enthielt der Pool aufgrund des Reservepools oder von Abbruchanfragen mehr Server als pool_size, wurde hingegen überhaupt keiner verdrängt. (#1597 )
  • Hängende TLS-Verbindungen behoben, wenn ein Paket über die Grenze des Paketpuffers hinausreicht, etwa bei SET application_name mit einem langen Wert. (#1531 )
  • Behoben, dass Antworten auf vorbereitete Anweisungen in falscher Reihenfolge gesendet wurden, wenn ein Stapel Parse- und Close-Nachrichten ohne dazwischenliegendes Sync mischte. (#1555 )
  • Fehlerhaftes Verhalten bei Parametern behoben, die in track_extra_parameters aufgeführt sind, vom Server aber nicht gemeldet werden, wenn ein Client sie in seinem Startpaket setzt. (#1576 )
  • Anmeldefehler behoben, wenn der Server seine Anmeldepakete auf mehrere TCP-Pakete verteilt, etwa wenn sich ein weiterer Proxy zwischen PgBouncer und PostgreSQL befindet. (#1446 )
  • Behoben, dass query_timeout Verbindungen schloss, obwohl keine Abfrage lief. (#1395 )
  • Das doppelte Senden einer NegotiateProtocolVersion-Nachricht behoben, wenn nicht sofort ein Server verfügbar war. (#1460 )
  • Behoben, dass die Spalte pool_size in SHOW USERS für Benutzer einen Wert anzeigte, für die keiner konfiguriert war. (#1489 )
  • Die Fehlermeldung für den Verwaltungsbefehl ENABLE korrigiert. (#1308 )
  • Die Kompilierung mit künftigen OpenSSL-Versionen korrigiert, die struct asn1_string_st zu einem opaken Typ machen. (#1440 )
  • Verhindert, dass der Compiler das Löschen sensibler kryptografischer Daten vom Stack wegoptimiert. (#1508 )
  • Das Linken von pgbevent.dll mit clang unter Windows korrigiert. (#1571 )
  • Pfade von Dateien auf der obersten Ebene des Release-Tarballs korrigiert, die als pgbouncer-X.Y.Z/./configure statt als pgbouncer-X.Y.Z/configure gespeichert waren. (#1549 )
  • Ein Speicherleck beim Lesen von track_extra_parameters aus der Konfiguration behoben. (#1510 )
  • Ein Speicherleck für jedes Startpaket behoben, das einen Protokollerweiterungsparameter (Präfix _pq_.) enthielt. Es konnte von nicht authentifizierten Clients ausgelöst werden. (#1540 )

PgBouncer 1.25.x

2026-05-08 - PgBouncer 1.25.2 - „Eine menschliche Note und eine neue Wendung im Titelrennen voller Ungewissheiten“

• Sicherheit

  • CVE-2026-6664 behoben: Ein Ganzzahlüberlauf beim Parsen von Netzwerkpaketen in PgBouncer vor 1.25.2 umgeht eine Bereichsprüfung und kann zu einem Absturz führen. Ein nicht authentifizierter Angreifer kann PgBouncer aus der Ferne mit einem fehlerhaften SCRAM-Authentifizierungspaket zum Absturz bringen.
  • CVE-2026-6665 behoben: Der SCRAM-Code in PgBouncer vor 1.25.2 prüfte beim Erstellen des Inhalts der SCRAM-Nachricht client-final-message den Rückgabewert von strlcat() nicht korrekt. Ein böswilliges Backend, das eine SCRAM-Nachricht server-final-message mit einer langen Nonce sendet, kann einen Stack-Überlauf auslösen.
  • CVE-2026-6666 behoben: Eine mögliche Nullzeigerreferenz in PgBouncer vor 1.25.2 konnte zu einem Absturz führen, wenn ein Server eine Fehlerantwort ohne SQLSTATE-Feld sendet.
  • CVE-2026-6667 behoben: PgBouncer vor 1.25.2 führte für den Verwaltungsbefehl KILL_CLIENT keine angemessene Berechtigungsprüfung durch. Alle Benutzer mit Zugriff auf die Verwaltungskonsole, der selbst eine Berechtigung erfordert, konnten diesen Befehl ausführen. Er sollte nur Benutzern erlaubt sein, die im Parameter admin_users aufgeführt sind.

• Fehlerbehebungen

  • Die Dokumentation des Parameters default_pool_size präzisiert.
  • Die Dokumentation zu client_tls13_ciphers und server_tls13_ciphers korrigiert.

2025-12-03 - PgBouncer 1.25.1 - „Vor Weihnachten noch etliche Fehler beheben“

• Sicherheit

  • CVE-2025-12819 behoben: Vor dieser Version konnte ein nicht authentifizierter Angreifer während der Authentifizierung beliebiges SQL ausführen, indem er in der StartupMessage einen bösartigen search_path-Parameter übergab. Systeme, bei denen ALLE folgenden Konfigurationen vorliegen, sind betroffen:

    1. track_extra_parameters enthält search_path (keine Standardkonfiguration; vermutlich nur bei Konfigurationen mit Citus oder PostgreSQL 18 eingestellt)
    2. auth_user ist auf eine nicht leere Zeichenkette gesetzt (keine Standardkonfiguration)
    3. auth_query ist ohne vollständig qualifizierte Objektnamen konfiguriert (Standardkonfiguration; der Operator < ist nicht mit einem Schema qualifiziert)

• Fehlerbehebungen

  • Fehler bei der Ad-hoc-SCRAM-Authentifizierung nach erneutem Verbindungsaufbau zum Server behoben (#1432 , in 1.25.0 eingeführt)
  • Fehlende Typdefinitionen für ungewöhnliche Architekturen ohne SIMD-Unterstützung hinzugefügt (#1414 , in 1.25.0 eingeführt)
  • Störende Warnmeldung entfernt, wenn der Client die Verbindung schließt, bevor er Daten sendet (#1420 , in 1.25.0 eingeführt)
  • Eine mögliche Dereferenzierung eines NULL-Zeigers verhindert (#1423 , in 1.25.0 eingeführt)
  • Ein mögliches Speicherleck behoben (#1422 , in 1.25.0 eingeführt)
  • Das Parsen von SCRAM-Servernachrichten korrigiert (#1431 , in 1.25.0 eingeführt)

2025-11-09 - PgBouncer 1.25.0 - „Die Version mit LDAP-Unterstützung“

• Funktionen
  • LDAP-Authentifizierung hinzugefügt! Sie lässt sich über eine HBA-Datei oder auth_ldap_options konfigurieren. (#731 )
  • Unterstützung für direkte TLS-Verbindungen auf der Clientseite hinzugefügt. Dadurch können Clients den schnelleren TLS-Verbindungsaufbau verwenden, der in PostgreSQL 17 eingeführt wurde. PgBouncer kann sich mit diesem schnelleren Verfahren (noch) nicht mit PostgreSQL-Servern verbinden. (#1359 )
  • Den Zustand idle zu SHOW CLIENTS hinzugefügt. (#1191 )
  • Die Einstellung transaction_timeout hinzugefügt, sowohl global als auch auf Benutzerebene. (#1242 )
  • Eine NOTICE-Nachricht wird an einen Client gesendet, wenn er länger als 5 Sekunden in der Warteschlange steht, ohne eine Verbindung zu erhalten. Mit query_wait_notify lässt sich diese Dauer ändern oder die Benachrichtigung deaktivieren. (#1264 )
  • Die Einstellung scram_iterations hinzugefügt, damit Betreiber zwischen Sicherheit und Authentifizierungsgeschwindigkeit abwägen können (#1339 )
  • client_tls13_ciphers und server_tls13_ciphers zur Auswahl der zu aktivierenden TLSv1.3-Cipher-Suites hinzugefügt. (#1352 )
• Änderungen
  • Die Leistung der Ad-hoc-SCRAM-Authentifizierung erheblich verbessert. (#1338 )
  • KILL kann ohne Angabe einer Datenbank ausgeführt werden. Dies bedeutet jetzt, dass KILL für alle Datenbanken ausgeführt wird. (#1317 )
  • Die Health-Check-Abfrage sendet standardmäßig eine leere Abfrage statt SELECT 1. (#1233 )
  • Die vollständige PAM-Warteschlange wird als Warnung protokolliert. Dadurch lässt sich die Ursache der hierdurch verlangsamten Abfragen leichter ermitteln. (#1297 )
  • Der Befehl RELOAD meldet jetzt alle beim Neuladen aufgetretenen Fehler. (#1231 )
  • Während des Herunterfahrens bleibt der PgBouncer-Unix-Socket für Verwaltungsverbindungen zugänglich. So können Betreiber leichter ermitteln, warum ein PgBouncer-Prozess nicht herunterfährt, und/oder für festhängende Verbindungen manuell KILL_CLIENT ausführen. (#1305 )
  • mkauth.py so geändert, dass kein veraltetes drittes Feld mehr hinzugefügt wird (#1365 )
  • Die FATAL-Meldungen in den Funktionen disconnect_client und disconnect_server verbessert. (#1382 )
  • Die veraltete OpenSSL-Funktion EVP_PKEY_get0_EC_KEY wird nicht mehr verwendet. Sie konnte bei bestimmten FIPS-Implementierungen Probleme verursachen. (#1384 )
• Fehlerbehebungen
  • Einen Absturz bei langen Passwörtern (1024 Zeichen oder mehr) behoben. (#1215 )
  • Verbindungen mit mehreren Hosts bei Verwendung von server_tls_sslmode=verify-full korrigiert. (#1303 )
  • Einen seltenen FATAL-Fehler beim Weiterleiten von Abbruchanfragen behoben. (#1383 )
  • Die Sortierung der Parameter in SHOW CONFIG korrigiert. (#1403 )
  • Das Parsen des Startpakets robuster gemacht. (#1407 )

PgBouncer 1.24.x

2025-04-16 - PgBouncer 1.24.1 - „CVE-2025-2291 VALID UNTIL gestern“

• Sicherheit

  • CVE-2025-2291 behoben: Bisher berücksichtigte PgBouncer beim Abrufen von Passwort-Hashes mit auth_query nicht den Wert VALID UNTIL eines Benutzerpassworts. Wurde PgBouncer als transparenter Proxy vor Postgres eingesetzt, konnte es daher bereits abgelaufene Passwörter akzeptieren. Zur Behebung wurden die standardmäßige auth_query und die Beispiele für benutzerdefinierte auth_query-Funktionen in der Dokumentation so geändert, dass sie VALID UNTIL berücksichtigen. Wenn Sie eine benutzerdefinierte auth_query verwenden, sollten Sie diese entsprechend aktualisieren. Bei Verwendung der standardmäßigen auth_query können Sie entweder auf PgBouncer 1.24.1 aktualisieren oder die Konfiguration einer älteren PgBouncer-Version so ändern, dass sie die neue standardmäßige auth_query verwendet.

• Fehlerbehebungen

  • Die PAM-Unterstützung repariert, indem die Unterstützung für pam-Authentifizierung in HBA-Dateien zurückgenommen wurde. (#1291 ) (Fehler in 1.24.0 eingeführt)
  • Einen Fehler beim Verringern des Zählers für Benutzerverbindungen behoben. Diese Korrektur war im Tag 1.24.0 auf GitHub enthalten, fehlte aber im Release-Tarball. (#1238 ) (Fehler in 1.24.0 eingeführt)
  • test_load_balance_hosts.py zum Tarball hinzugefügt. (#1282 )
  • Probleme in Tests behoben, damit Debian-Paketbetreuer sie ausführen können. (#1266 , #1250 )

• Dokumentation

  • Das Beispiel für auth_query aktualisiert, sodass es einen sicheren search_path setzt. (#1245 )

2025-01-10 - PgBouncer 1.24.0 - „Neues Jahr, neuer Türsteher“

• Funktionen

  • Unterstützung für Type=notify-reload für systemd hinzugefügt. Dies erfordert systemd ab Version 253. (#1148 )
  • Den Befehl KILL_CLIENT zur Verwaltungskonsole hinzugefügt. Damit lässt sich eine Clientverbindung zwangsweise beenden. (#1147 )
  • Die Einstellung max_user_client_connections hinzugefügt, sowohl global als auch auf Benutzerebene. (#1137 )
  • Die Einstellung max_db_client_connections hinzugefügt, sowohl global als auch auf Datenbankebene. (#1138 )
  • Den Zähler current_client_connections zur Ausgabe von SHOW USERS und SHOW DATABASES hinzugefügt. (#1137 , #1138 )
  • Den Parameter load_balance_hosts hinzugefügt, mit dem sich festlegen lässt, dass keine Lastverteilung zwischen Hosts erfolgt. (#736 )
  • Nutzungszähler für vorbereitete Anweisungen in SHOW STATS verfügbar gemacht. (#1192 )
  • Die Einstellung client_idle_timeout hinzugefügt. (#1189 )
  • query_timeout und reserve_pool_size auf Benutzerebene hinzugefügt. (#1180 , #1228 )
  • Unterstützung für pam-Authentifizierung in HBA-Dateien aktiviert. (#326 )

• Änderungen

  • Verbindungen werden bei RELOAD nicht erneuert, wenn die TLS-Konfiguration unverändert ist. Bisher wurden bei RELOAD alle vorhandenen TLS-Verbindungen erneuert, was zu einem vorübergehenden, aber erheblichen Leistungseinbruch führen konnte. Dies geschieht jetzt nur noch, wenn sich die TLS-Einstellungen tatsächlich ändern. (#1157 )
  • Die Unterstützung vorbereiteter Anweisungen ist standardmäßig aktiviert; max_prepared_statements ist jetzt standardmäßig auf 200 gesetzt. Diese Änderung der Standardwerte sollte nur Clients betreffen, die tatsächlich vorbereitete Anweisungen verwenden. Wenn Sie vorbereitete Anweisungen verwenden, empfiehlt es sich, die Einschränkungen dieser Unterstützung in unserer Dokumentation zu lesen. (#1144 )
  • Sockets, Clients und Server lassen sich in der Verwaltungsausgabe jetzt anhand einer eindeutigen ID identifizieren. Bisher dienten dazu ihre Zeiger, die nach dem Trennen der Verbindung jedoch häufig für neue Clients wiederverwendet wurden. (#1172 )
  • Klarere Fehlermeldung für eine leere PID-Datei. (#1195 )
  • Bei einem Fehlschlag von server_login_retry wird der ursprüngliche Fehler an den Client zurückgegeben. (#1152 )
  • Bei einem Fehler in auth_query wird der ursprüngliche Serverfehler protokolliert. (#1187 )
  • Der Wert 0 für default_pool_size bedeutet unbegrenzte Größe. (#1227 )
  • Die Datenbankeinstellung reserve_pool in reserve_pool_size umbenannt. Der bisherige Name bleibt als Alias für den neuen Namen erhalten. (#1232 )

• Fehlerbehebungen

  • Verschiedene unwahrscheinliche Fehlerfälle, etwa OOM-Fehler, werden besser behandelt. Sie konnten zuvor Abstürze oder Speicherlecks verursachen. (#1108 , #1101 , #1099 , #1169 , #1202 )
  • Den Standardwert für server_tls_sslmode in der Beispielkonfiguration korrigiert. (#1133 )
  • Den Hinweis auf einen ungültigen Alias für server_tls_protocols aus der Dokumentation entfernt. (#1155 )
  • Einen Fehler bei gleichzeitiger Verwendung von auth_query und Replikationsverbindungen behoben. Er führte in solchen Konfigurationen zu Verbindungsfehlern. (#1166 )
  • Abbruchanfragen von Clients werden ignoriert, während PgBouncer Servereinstellungen konfiguriert. (#298 )

PgBouncer 1.23.x

2024-08-02 - PgBouncer 1.23.1 - „Alles wieder in Ordnung“

• Fehlerbehebungen
  • Einen möglichen Speicherzugriffsfehler nach dem Neuladen der PgBouncer-Konfiguration behoben. (#1105 ) (Fehler in 1.23.0 eingeführt)
  • Alle bekannten Abstürze in put_in_order behoben. (#1120 ) (neue Abstürze wurden in 1.23.0 eingeführt)
  • Fehlende, für Tests benötigte Dateien zum Release-Tarball hinzugefügt. (#1124 ) (die Dateien fehlten seit 1.23.0)

2024-07-03 - PgBouncer 1.23.0 - „Auf zu neuen Anfängen“

• Funktionen

  • Unterstützung für rollierende Neustarts hinzugefügt. SIGTERM fährt den PgBouncer-Prozess nicht mehr sofort herunter. Stattdessen erfolgt jetzt ein „besonders sicheres Herunterfahren“: Vor dem Herunterfahren wird gewartet, bis alle Clients ihre Verbindung getrennt haben. Das neue SIGTERM-Verhalten ermöglicht rollierende Neustarts mehrerer PgBouncer-Prozesse hinter einem Load-Balancer oder mehrerer Prozesse, die mit so_reuseport am selben Port lauschen. Dies ist eine kleine inkompatible Änderung. Wenn Sie sich in Ihrer Dockerfile- oder Systemd-Service-Datei auf das bisherige SIGTERM-Verhalten verlassen haben, sollten Sie jetzt SIGQUIT verwenden. (#902 )
  • Unterstützung für Benutzernamenzuordnungen bei den Authentifizierungsmethoden cert und peer hinzugefügt. Diese Funktion bietet die Flexibilität, dass der die Verbindung aufbauende Benutzer nicht dem Datenbankbenutzer entsprechen muss. Benutzernamenzuordnungen in PgBouncer funktionieren sehr ähnlich wie in Postgres, mit den in der Dokumentation aufgeführten Ausnahmen. (#996 )
  • Unterstützung für Replikationsverbindungen über PgBouncer hinzugefügt. (#876 )

• Änderungen

  • Die Verbindungsliste in der Ausgabe von SHOW USERS verbessert. (#1040 )
  • pool_size kann pro Benutzer konfiguriert werden. (#1049 )
  • server_lifetime kann pro Datenbank konfiguriert werden. (#1057 )
  • Unterstützung für die Auflistung dynamisch erzeugter Benutzer in der Ausgabe von SHOW USERS hinzugefügt. (#1052 )
  • Unterstützung für den Adresstyp all in der hba-Konfiguration hinzugefügt. (#1078 )
  • Unterstützung für automatische Neustarts bei Verwendung von systemd hinzugefügt. (#1080 )
  • Die erforderliche Mindestversion von c-ares auf 1.9.0 erhöht (#1076 )

• Fehlerbehebungen

  • Probleme bei der Verarbeitung großer und unvollständiger Startpakete behoben. (#1058 )
  • Unterstützung für das Format --config=value im Startparameter options hinzugefügt. (#1064 )
  • Die Berechnung der Metrik avg_wait_time korrigiert. (#727 )
  • Unterstützung für das Aushandeln der Postgres-Protokollversion mit dem Client hinzugefügt. (#1007 )
  • Die Erfassung einer ausstehenden Anfrage für auth_query hinzugefügt. (#1034 )
  • Mehrere Verbesserungen an Dokumentation und CI.

PgBouncer 1.22.x

2024-03-04 - PgBouncer 1.22.1 - „Sommer in Bangalore“

• Fehlerbehebungen
  • Probleme behoben, die von manchen Clients durch COPY FROM STDIN-Abfragen verursacht wurden. Solche Abfragen konnten Speicherlecks, Leistungseinbußen und Fehlverhalten bei vorbereiteten Anweisungen verursachen. (#1025 ) (Fehler in 1.21.0 eingeführt)
  • Fehlende Tests zum Release-Tarball hinzugefügt (#1026 ) (die Tests fehlten seit 1.19.0 & 1.21.0)

2024-01-31 - PgBouncer 1.22.0 - „DEALLOCATE ALL“

• Funktionen

  • Unterstützung für DEALLOCATE ALL und DISCARD ALL hinzugefügt, wenn max_prepared_statements auf einen Wert ungleich null gesetzt ist (normales DEALLOCATE wird weiterhin nicht unterstützt) (#972 )
  • auth_query kann pro Datenbank konfiguriert werden (#979 )

• Änderungen

  • Die Einstellungen in der empfohlenen systemd-Unit-Datei verbessert (#983 )
  • Die Fail-Fast-Logik behandelt alle Szenarien, in denen keine funktionierenden Verbindungen zur Datenbank mehr bestehen und keine hergestellt werden können (#998 )
  • Mehrere Verbesserungen an der Dokumentation

• Fehlerbehebungen

  • Ein Problem in PG14+ behoben, bei dem PgBouncer für jede Transaktion SET DateStyle='ISO' sendete (#879 )
  • Die Behandlung eines leeren application_name korrigiert (#999 )
  • Das Bauen unter Windows mit OpenSSL 3.2.0 korrigiert (#1009 )

PgBouncer 1.21.x

2023-10-16 - PgBouncer 1.21.0 - „Die Version mit vorbereiteten Anweisungen“

• Funktionen

  • Unterstützung für benannte vorbereitete Anweisungen auf Protokollebene hinzugefügt! Dies ist vermutlich eine der am häufigsten gewünschten PgBouncer-Funktionen. Vorbereitete Anweisungen zusammen mit PgBouncer können die CPU-Last des Systems erheblich senken, sowohl auf der PgBouncer- als auch auf der PostgreSQL-Seite. In synthetischen Benchmarks erhöhte diese Funktion den Abfragedurchsatz je nach Arbeitslast um 15% bis 250%. Um die neue Funktion zu nutzen, müssen Sie die neue Einstellung max_prepared_statements auf einen Wert ungleich null setzen. Der genaue Wert hängt von der Arbeitslast ab, aber 100 dürfte angemessen sein. Einzelheiten zu Funktionsweise, Einschränkungen und Optimierung des Werts enthält die Dokumentation zu max_prepared_statements . Anschließend müssen Sie sicherstellen, dass Ihre Clientbibliothek tatsächlich vorbereitete Anweisungen verwendet. Wie dies geschieht, unterscheidet sich je nach Client; Sie sollten daher die Dokumentation des verwendeten Clients heranziehen. Die Funktion wurde vor der Veröffentlichung sehr gründlich getestet. Aufgrund ihrer Komplexität können jedoch durchaus noch Leistungsprobleme oder Fehler vorhanden sein. Bitte melden Sie solche Probleme, wenn Sie sie entdecken. (#845 )

• Änderungen

  • Die Sicherheit der OpenSSL-Einstellungen verbessert; die verwendeten Standardwerte waren SEHR veraltet. Ab dieser Version entsprechen die Standardwerte den OpenSSL-Standardwerten des Systems, auf dem PgBouncer läuft. (#948 & libusual/#41 )
  • PgBouncer verwendet jetzt nach Möglichkeit OpenSSL zur Berechnung von MD5-Hashes. Dies ist für einen FIPS-konformen Einsatz von PgBouncer erforderlich. (#949 )
  • min_pool_size wird bei Pools mit einem erzwungenen Benutzer auch dann eingehalten, wenn keine Clients mit PgBouncer verbunden sind (#947 )
  • Die Kodierung von peer_id im Abbruch-Token durch PgBouncer wurde geändert. Deshalb funktioniert das Peering zwischen unterschiedlichen PgBouncer-Versionen nicht, wenn sie nicht alle auf derselben Seite der Versionsgrenze v1.21.0 liegen. (#945 )

• Fehlerbehebungen

  • Den Absturz mit der Fehlermeldung “FATAL in function client_proto(): bad client state: 6/7” behoben (#928 ) (Fehler in 1.18.0 eingeführt)
  • Den Absturz mit der Fehlermeldung “FATAL in function server_proto(): server in bad state: 11” behoben (#927 ) (Fehler in 1.18.0 eingeführt)
  • Die Protokollierungsstufe für das Senden von Abbruchanfragen verringert (#903 )
  • Das slog-Protokollpräfix für Peers korrigiert (#922 )
  • Tippfehler in der Dokumentation korrigiert (#932 )
  • Von der statischen Analyse erkannte Fehler behoben (#943 )
  • Bei vorübergehenden FATAL-Fehlern während der Anmeldung werden nicht alle wartenden Clients beendet (#946 )
  • Eine automatisch erzeugte Datenbank wird verwendet, wenn die Datenbank in auth_dbname nicht explizit konfiguriert ist (#921 )

• Bereinigungen

  • Die Unterstützung für udns entfernt (#938 )

PgBouncer 1.20.x

2023-08-09 - PgBouncer 1.20.1 - „Optionale Optionen“

• Fehlerbehebungen
  • Eine Regression behoben, bei der das Eintragen von options in ignore_startup_parameters nicht mehr dazu führte, dass unbekannte Parameter im Startparameter options ignoriert wurden. (#908 ) (Regression in 1.20.0 eingeführt)
  • Einen verwirrenden Tippfehler in der Dokumentation korrigiert (#917 )

2023-07-20 - PgBouncer 1.20.0 - „Hier gehört ein lustiger Name hin“

• Abkündigungen

  • Die Option für Online-Neustarts gilt jetzt als veraltet. Diese Funktion wurde in den letzten Jahren kaum gepflegt. Sie hat mehrere bekannte Probleme, und neu hinzugefügte Funktionen unterstützen sie häufig nicht. Heute wird für Online-Neustarts die Verwendung der Funktionen so_reuseport und peers empfohlen. Damit können mehrere unterschiedliche PgBouncer-Prozesse am selben Port laufen. Indem Sie diese Prozesse nacheinander neu starten, können Sie sicherstellen, dass immer ein PgBouncer-Prozess am gewünschten Port lauscht. (#894 )

• Funktionen

  • track_extra_parameters eingeführt, um im Transaktions-Pooling-Modus weitere Parameter nachverfolgen zu können. Bisher verfolgte PgBouncer nur application_name, DateStyle, TimeZone und standard_conforming_strings. Jetzt wird auch IntervalStyle standardmäßig nachverfolgt. Durch Ändern von track_extra_parameters lassen sich weitere Einstellungen nachverfolgen, jedoch nur solche, die PostgreSQL an den Client zurückmeldet . Bei Verwendung von Citus 12.0+ sorgt Citus dafür, dass PostgreSQL auch search_path an den Client zurückmeldet. Wenn Sie Citus verwenden, können Sie deshalb search_path zur Einstellung track_extra_parameters hinzufügen. (#867 )
  • SQLSTATE wird während der Authentifizierung weitergeleitet. Dadurch lässt sich erkennen, ob eine Datenbank nicht existiert, wie es Npgsql (ein .NET-Datenprovider für PostgreSQL) tut. (#814 )
  • Den Standardwert von server_tls_sslmode auf prefer geändert. (#866 )
  • Unterstützung für den Startparameter options hinzugefügt. Dies ermöglicht die Verwendung der Umgebungsvariable PGOPTIONS, die psql und libpq unterstützen . Mit dieser Variable lassen sich beliebige PostgreSQL-Parameter beim Start setzen. Dies funktioniert nur für PostgreSQL-Parameter, die PgBouncer über track_extra_parameters nachverfolgt. (#878 )

• Fehlerbehebungen

  • Kein Absturz mehr, wenn die Verwaltungsdatenbank pgbouncer als auth_dbname verwendet wird. Dies wird weiterhin nicht unterstützt, führt jetzt aber zu einer klaren Fehlermeldung statt zu einem Absturz. (#817 )
  • Den Namen von peer_cache in SHOW MEM korrigiert. Bisher wurde er fälschlich als db_cache angezeigt. (#864 )
  • Die Verwechslung von src/dst im Protokoll korrigiert. PgBouncer protokollierte eine Quell-IP, obwohl die Ziel-IP gemeint war. (#880 )
  • Verwaltungsverbindungen über Unix-Sockets werden nur protokolliert, wenn log_connections auf 1 gesetzt ist. (#883 )

PgBouncer 1.19.x

2023-05-31 - PgBouncer 1.19.1 - „Sonniger Frühling“

Dies ist eine Wartungsversion, die einige kürzlich eingeführte Fehler behebt:

• Fehlerbehebungen
  • Behoben: FATAL in function disconnect_client(): bad client state: 0 (#846 ) (Fehler in 1.18.0 eingeführt)
  • Behoben: FATAL in function server_proto(): server in bad state: 14 (#849 ) (Fehler in 1.18.0 eingeführt)
  • Für die Ausführung der Python-Tests erforderliche Dateien zum Release-Tarball hinzugefügt (#852 ) (neue Tests in 1.19.0 eingeführt)

2023-05-04 - PgBouncer 1.19.0 - „Auf die altmodische Art, von Menschen gemacht“

• Funktionen

  • Die Option auth_dbname hinzugefügt. Sie legt fest, in welcher Datenbank auth_query ausgeführt wird. (#764 )
  • Den Befehl SHOW STATE hinzugefügt. Er zeigt an, ob PgBouncer aktiv, pausiert oder angehalten ist. (#528 )
  • Unterstützung für Peering zwischen PgBouncer-Prozessen hinzugefügt. Damit lässt sich PgBouncer so konfigurieren, dass Abbruchanfragen auch dann weiter funktionieren, wenn sich mehrere unterschiedliche PgBouncer-Prozesse hinter einem einzigen Load-Balancer befinden. (#666 )
  • Eine eigene Einstellung cancel_wait_timeout hinzugefügt. Sie bestimmt, nach welcher Zeit das Weiterleiten einer Abbruchanfrage aufgegeben wird. Der Standardwert beträgt 10 Sekunden. (#833 )
  • Neues Testframework (#792 )

• Fehlerbehebungen

  • Ein mögliches Speicherleck bei fehlgeschlagenem TLS-Handshake behoben. (#796 )
  • Genauere Fehlermeldungen für nicht unterstützte Befehlszeilenoptionen unter Windows. (#620 )
  • Den Aufruf von disconnect_server für einen Server im Zustand BEING_CANCELED korrigiert. (#815 ) (in 1.18.0 eingeführt)
  • Beim Empfang von SIGTERM wird PgBouncer nicht mit einem Status ungleich null beendet. (#834 )
  • Der Start wird mit einem Fehler abgebrochen, wenn ein Socket in unix_socket_dir nicht erstellt werden konnte. (#830 )
  • Der Start wird mit einem Fehler abgebrochen, wenn an keiner der Adressen in listen_addr gelauscht werden konnte. (#838 )
  • Beim Fehlschlagen von sbuf_connect werden mehr Warnungen mit zusätzlichen Informationen ausgegeben. Dies ist besonders hilfreich, wenn das Erstellen von Unix-Sockets fehlschlägt. (#837 )

• Bereinigungen

  • Verschiedene CI-Aktualisierungen für bessere Leistung
  • AppVeyor entfernt

PgBouncer 1.18.x

2022-12-12 - PgBouncer 1.18.0 - „Kein echtes Rätsel“

• Funktionen

  • application_name zur Ausgabe von SHOW CLIENTS/SERVERS/SOCKETS hinzugefügt (#449 )
  • Informationen über Abbruchanfragen zur Ausgabe von SHOW CLIENTS/SERVERS/POOLS hinzugefügt (#782 )

• Fehlerbehebungen

  • Die Operation sbuf_send_pending schlägt fehl, wenn der Ziel-Socket geschlossen ist (#652 )
  • Einige mögliche Abstürze behoben (#700 , #730 )
  • Einen Überlauffehler bei der Funktion für kommagetrennte Hostlisten behoben, der die Verbindung auf einen Unix-Socket umleitete (#747 )
  • Verbindungen werden nicht verdrängt, um min_pool_size zu erreichen (#648 )
  • SHOW HELP mit PostgreSQL 15 korrigiert (#769 )
  • Eine Race Condition bei der Verarbeitung von Abbruchanfragen für Abfragen behoben. Eine Abbruchanfrage für einen Client konnte die Abfrage eines anderen Clients abbrechen. Dies konnte geschehen, wenn PgBouncer die Abbruchanfrage erst erhielt, nachdem die eigentlich abzubrechende Abfrage bereits von selbst abgeschlossen war. (#717 )

• Bereinigungen

  • Verschiedene CI-Aktualisierungen

PgBouncer 1.17.x

2022-03-23 - PgBouncer 1.17.0 - „Eine Grenze wurde gezogen“

• Funktionen

  • Eine Datenbankdefinition kann eine kommagetrennte Hostliste angeben. Die Verbindungen zu den Hosts werden im Round-Robin-Verfahren hergestellt.
  • Beim Verbinden mit einer nicht existierenden Datenbank wird der Fehler (“no such database”) jetzt erst nach der Authentifizierung gemeldet. Dies verhindert, dass nicht authentifizierte Clients auskundschaften können, welche Datenbanken existieren. (Dies ähnelt der Änderung in Version 1.15.0, fehlende Benutzer erst nach der Authentifizierung zu melden.)
  • Fehler beim Trennen einer Serververbindung werden vor der Anmeldung nicht an den Client gesendet. Sie könnten einem noch nicht angemeldeten Client Informationen offenlegen, die nicht uneingeschränkt öffentlich sind, etwa Konfigurationsdetails.
  • Die maximale Passwortlänge erneut erhöht. Offenbar reichte die letzte Erhöhung nicht lange genug aus.
  • Das automatische Neuladen von auth_file entfernt. auth_file wird jetzt nur noch beim Neuladen der Konfigurationsdatei erneut gelesen, nicht mehr automatisch bei jeder Änderung.
  • Der Windows-Build enthält jetzt eine Ressourcendatei mit Versionsinformationen.
  • Die in der CI erstellten Windows-Builds sind jetzt statisch gelinkt und können daher ohne weitere Abhängigkeiten direkt verwendet werden.

• Fehlerbehebungen

  • Die Unterstützung für OpenSSL 3 korrigiert. Frühere Versionen stürzten ab.
  • Die Fail-Fast-Logik wird beim Verbindungsaufbau nicht angewendet. Dies ist Teil der oben genannten Änderung, Serverfehler nicht vor der Authentifizierung zu melden. Es behebt außerdem einen besonderen Fall bei der SCRAM-Durchleitung: Der clientseitige Authentifizierungsaustausch muss zugelassen werden, damit die serverseitige Verbindung durch erneute Authentifizierung repariert werden kann. Der Fail-Fast-Mechanismus greift weiterhin unmittelbar nach der Authentifizierung, sodass das tatsächlich beobachtete Verhalten in den meisten Fällen gleich bleibt.
  • auth_type in der Beispielkonfiguration pgbouncer.ini auf md5 geändert, entsprechend dem eingebauten Standardwert. Manche setzen diese Datei als Standardkonfiguration ein; prüfen Sie daher, ob die geänderte Konfiguration für Ihren Einsatz weiterhin sinnvoll ist.
  • Einen Absturz beim Beenden von Builds mit aktivierten Assertions behoben.
  • Dokumentation und Verhalten von tcp_defer_accept verbessert. Die Angaben zum Standardwert waren falsch und irreführend. In manchen Fällen zeigte “show config” den falschen Wert. Ist die Option gesetzt, wird aber nicht unterstützt, wird jetzt außerdem ein Fehler ausgegeben, statt sie zu ignorieren; dies entspricht der Behandlung anderer plattformspezifischer Socket-Optionen.
  • Den Build mit c-ares unter Windows korrigiert. Unter Windows ist jetzt c-ares >=1.18.0 erforderlich.

• Bereinigungen

  • Die meisten Warnungen zu veralteten Funktionen von Autoconf >=2.70 beseitigt. Ältere Autoconf-Versionen werden weiterhin unterstützt.
  • Den Einsatz von Cirrus CI auf weitere Plattformen ausgeweitet.
  • Die Unterstützung für Travis CI entfernt.
  • Die Suchorte für die standardmäßige Root-CA-Datei aktualisiert, um weitere Plattformen wie Fedora/RHEL/CentOS abzudecken.
  • Alle Python-Skripte verwenden jetzt standardmäßig python3. Die Kompatibilität mit Python 2 wird nicht mehr gepflegt.
  • Die Skripte der Testsuite verwenden command -v statt des veralteten which.
  • Mehrere Fehlermeldungen umformuliert, damit deutlicher wird, auf welchen Befehl oder welche Konfigurationseinstellung sie sich beziehen.
  • Die Skripte der Testsuite benötigen GNU sed nicht mehr.
  • make check funktioniert jetzt unter Windows (die SSL-Testsuite allerdings noch nicht).
  • Dokumentiert, dass die Verwaltungskonsole nur das einfache Abfrageprotokoll unterstützt, und diesbezügliche Fehlermeldungen verbessert.

PgBouncer 1.16.x

2021-11-11 - PgBouncer 1.16.1 - „Tiefgang auf dem Prüfstand gegen stille Effizienz“

Dies ist eine Wartungsversion mit einer Sicherheitskorrektur.

• PgBouncer weist in seiner Rolle als Server zusätzliche Daten nach einem SSL- oder GSS-Verschlüsselungs-Handshake zurück.

  Ein Man-in-the-Middle-Angreifer, der Daten in die TCP-Verbindung einschleusen kann, konnte Klartextdaten am Anfang einer vermeintlich durch Verschlüsselung geschützten Datenbanksitzung platzieren. Dies ließ sich zum Senden gefälschter SQL-Befehle an den Server missbrauchen, allerdings nur, wenn PgBouncer keine Authentifizierungsdaten verlangte. (Eine PgBouncer-Konfiguration mit SSL-Zertifikatsauthentifizierung könnte tatsächlich darauf verzichten.) (CVE-2021-3935)

2021-08-09 - PgBouncer 1.16.0 - „Einen Jaguar abgewehrt“

• Funktionen

  • Das Neuladen von TLS-Einstellungen im laufenden Betrieb wird unterstützt. Beim Neuladen der Konfigurationsdatei werden geänderte TLS-Einstellungen automatisch wirksam.
  • Unterstützung für abstrakte Unix-Domain-Sockets hinzugefügt. Stellen Sie einem Unix-Domain-Socket-Pfad @ voran, um einen Socket im abstrakten Namensraum zu verwenden. Dies entspricht der zugehörigen Funktion von PostgreSQL 14.
  • Die maximale Länge von Passwörtern und Benutzernamen wurde auf 996 bzw. 128 erhöht. Verschiedene Cloud-Dienste erfordern dies.
  • Die Mindestgröße des Pools kann jetzt pro Datenbank festgelegt werden, ebenso wie die reguläre Poolgröße und die Größe des Reservepools.
  • Die Anzahl ausstehender Abbruchanfragen für Abfragen wird in SHOW POOLS angezeigt.

• Fehlerbehebungen

  • Beim Parsen der Konfiguration werden Fehler jetzt an vielen Stellen strenger behandelt. Wo früher möglicherweise ein Fehler protokolliert und die Verarbeitung fortgesetzt wurde, führen solche Konfigurationsfehler jetzt zu einem fehlgeschlagenen Start. So hätte es schon immer sein sollen, doch einige Codestellen setzten dies nicht korrekt um. Manche Benutzer könnten feststellen, dass ihre Konfigurationen schon immer fehlerhaft waren und nun nicht mehr funktionieren.
  • Die Verarbeitung von Abbruchanfragen für Abfragen korrigiert. Unter bestimmten Umständen schienen Abbruchanfragen lange festzuhängen. Dies sollte nicht mehr vorkommen. Tatsächlich können Abbruchanfragen jetzt bis zum Doppelten der Poolgröße reichen, sodass sie wirklich nicht mehr festhängen sollten. (#542 , #543 )
  • Die gemischte Verwendung von md5 und scram über hba korrigiert.
  • Den Build mit c-ares unter Windows korrigiert.
  • Die gefürchteten Meldungen “FIXME: query end, but query_start == 0” beseitigt. Ihre Ursache ist jetzt bekannt; sie sollten nicht mehr auftreten. (#565 )
  • Das Neuladen von default_pool_size, min_pool_size und reserve_pool_size korrigiert. Bisher funktionierte das Neuladen dieser Einstellungen nicht.

• Bereinigungen

  • Cirrus CI wird jetzt statt Travis CI verwendet .
  • Wie üblich wurden viele Tests hinzugefügt.
  • Die Protokollmeldung “unclean server” etwas präzisiert. Sie lautet jetzt “client disconnect while server was not ready” oder “client disconnect before everything was sent to the server”. Erstere kann auftreten, wenn die Clientverbindung geschlossen wird, während auf dem Server ein Transaktionsblock offen ist. Dies hatte einige Benutzer verwirrt.
  • “pgbouncer” kann nicht mehr als Datenbankname verwendet werden. Dieser Name ist für die Verwaltungskonsole reserviert; seine Verwendung als regulärer Datenbankname hatte nie wirklich korrekt funktioniert. Sie ist jetzt ausdrücklich untersagt.
  • Fehler, die vor dem Schließen der Verbindung an Clients gesendet werden, werden jetzt als FATAL statt nur als ERROR gekennzeichnet. Einige Clients reagierten andernfalls verwirrt. (#564 )
  • Compilerwarnungen mit GCC 11 beseitigt. (#623 )

PgBouncer 1.15.x

2020-11-19 - PgBouncer 1.15.0 - „Ich hab noch einen Koffer in Berlin“

• Funktionen

  • Die Meldung von Authentifizierungsfehlern verbessert. Die an Clients gesendeten Fehlermeldungen besagen jetzt nur noch, dass die Authentifizierung fehlgeschlagen ist, ohne weitere Einzelheiten. Details stehen im PgBouncer-Protokoll. Auch wenn der angeforderte Benutzer nicht existiert, wird die Authentifizierung vollständig durchgeführt und endet mit derselben allgemeinen Fehlermeldung. All dies verhindert, dass Clients die PgBouncer-Instanz nach Benutzernamen und anderen Informationen zur Authentifizierung auskundschaften. Das Verhalten ähnelt dem von PostgreSQL.
  • Nichts protokollieren, wenn ein Client die Verbindung sofort wieder trennt. Dies vermeidet unnötige Protokolleinträge, wenn Überwachungssysteme lediglich eine TCP/IP-Verbindung öffnen und ohne Senden von Daten wieder trennen.
  • Das systemd-Journal zur Protokollierung verwenden, wenn es im Einsatz ist. Wird erkannt, dass stderr ins systemd-Journal geleitet wird, werden die nativen systemd-Funktionen zur Protokollausgabe verwendet. Dies vermeidet doppelte Zeitstempel und Prozess-IDs und macht das Protokoll übersichtlicher. Außerdem werden Metadaten wie der Schweregrad ergänzt, sodass die Meldungen nützliche Metadaten enthalten, wenn das Journal an syslog weitergeleitet wird.
  • Ein Teil der Testsuite kann jetzt unter Windows ausgeführt werden.
  • SHOW CONFIG zeigt jetzt auch die Standardwerte der Einstellungen an.

• Fehlerbehebungen

  • Die Option so_reuseport unter FreeBSD korrigiert. Der ursprüngliche Code in PgBouncer 1.12.0 funktionierte unter FreeBSD tatsächlich nicht. (#504 )
  • Die Kompilierung auf Systemen mit älteren systemd-Versionen repariert. Sie war in 1.14.0 beschädigt worden. (#505 )
  • Das Makefile-Ziel zum Erstellen von ZIP-Paketen mit Windows-Binärdateien repariert.
  • Lange Befehlszeilenoptionen funktionieren jetzt auch unter Windows.
  • Das Verhalten der globalen Einstellung auth_user korrigiert. Das alte Verhalten war verwirrend und fehleranfällig, weil es von der Reihenfolge in der Konfigurationsdatei abhing. Dies ist nicht mehr der Fall. (#391 , #393 )

• Bereinigungen

  • Stabilität und Portierbarkeit der Tests verbessert.
  • Den Autoconf-bezogenen Code modernisiert.
  • Compilerwarnungen zu veralteten Funktionen von OpenSSL 3.0.0 deaktiviert.

PgBouncer 1.14.x

2020-06-11 - PgBouncer 1.14.0 - „Die wiedergefundene Magie“

• Funktionen

  • SCRAM-Authentifizierungsdurchleitung hinzugefügt. Damit lassen sich verschlüsselte SCRAM-Secrets in PgBouncer (aus userlist.txt oder auth_query) für die Anmeldung bei Servern verwenden.
  • Unterstützung für systemd-Socket-Aktivierung hinzugefügt. Dies ist besonders nützlich, um systemd auf Systemen mit eingeschränktem Zugriff auf /var/run/postgresql die Erstellung der Unix-Domain-Sockets zu überlassen.
  • Unterstützung für Unix-Domain-Sockets unter Windows hinzugefügt.

• Bereinigungen

  • Eine alternative, kleinere Beispielkonfiguration pgbouncer-minimal.ini für Tests oder den Einsatz hinzugefügt.

PgBouncer 1.13.x

2020-04-27 - PgBouncer 1.13.0 - „Mein Lieblingsspiel“

• Funktionen

  • Die Konfigurationseinstellung tcp_user_timeout zum Setzen der entsprechenden Socket-Option hinzugefügt.
  • client_tls_protocols und server_tls_protocols haben jetzt den Standardwert secure. Damit sind nur TLS 1.2 und TLS 1.3 aktiviert. Ältere Versionen werden weiterhin unterstützt, sind lediglich nicht standardmäßig eingeschaltet.
  • Unterstützung für systemd-Dienstbenachrichtigungen hinzugefügt. Damit lassen sich derzeit Service-Units mit Type=notify verwenden. Eine weitergehende Integration ist für zukünftige Versionen geplant.

• Fehlerbehebungen

  • Mehrzeilige Protokollmeldungen korrigiert (libusual #24 )
  • Von auth_query zurückgegebene Nullwerte für Benutzernamen korrekt behandeln (#340 )

• Bereinigungen

  • Die Dateien zur Debian-Paketerstellung unter debian entfernt. Es wird empfohlen, die Pakete von https://apt.postgresql.org/ zu verwenden.
  • Zahlreiche Korrekturen und Verbesserungen in der Testsuite
  • Die Tests versuchen standardmäßig nicht mehr, sudo zu verwenden. Dies kann jetzt durch Setzen der Umgebungsvariable USE_SUDO explizit aktiviert werden.
  • Die Nutzung der libevent-API wurde auf Schnittstellen im Stil von Version 2 umgestellt; die veralteten Schnittstellen von Version 1 werden nicht mehr verwendet.

PgBouncer 1.12.x

2019-10-17 - PgBouncer 1.12.0 - „Es geht ums Lernen und Besserwerden“

Diese Version enthält zahlreiche kleinere Erweiterungen und Fehlerbehebungen.

• Funktionen

  • Eine Einstellung zum Aktivieren der Socket-Option SO_REUSEPORT hinzugefügt. Auf manchen Betriebssystemen ermöglicht dies, mehrere PgBouncer-Instanzen auf demselben Host am selben Port lauschen zu lassen, wobei der Kernel die Verbindungen automatisch verteilt.
  • Eine Einstellung für die Verwendung einer vom Betriebssystem getrennten resolv.conf-Datei hinzugefügt. Damit lassen sich eigene DNS-Server und gegebenenfalls weitere DNS-Optionen festlegen.
  • Die Ausgabe von SHOW VERSION wird als normale Ergebniszeile statt als NOTICE-Nachricht gesendet. Das erleichtert die Verarbeitung und entspricht dem Verhalten anderer SHOW-Befehle.

• Fehlerbehebungen

  • Statistikspalten werden als numeric statt als bigint gesendet. Dies verhindert Fehler in einigen Clientbibliotheken bei Werten, die den Wertebereich von bigint überschreiten. (#360 , #401 )
  • Ein Problem behoben, bei dem PAM-Benutzer ihr Passwort verloren. (#285 )
  • Clients mit aktiviertem SCRAM Channel Binding werden akzeptiert. Bisher schlug die Verbindung mit PgBouncer in bestimmten Situationen fehl, wenn der Client Channel Binding unterstützte (also PostgreSQL 11+). PgBouncer unterstützt Channel Binding nicht. Diese Änderung korrigiert lediglich die Unterstützung für Clients, die es anbieten.
  • Die Kompilierung mit neueren Versionen von musl-libc (verwendet von Alpine Linux) korrigiert.

• Bereinigungen

  • Das Ziel make check hinzugefügt. Damit lassen sich alle Tests mit einem einzigen Befehl ausführen.
  • Verweise auf das PostgreSQL-Wiki entfernt. Alle Informationen stehen jetzt entweder in der PgBouncer-Dokumentation oder auf der Website.
  • Die Unterstützung für Libevent 1.x entfernt. Libevent 2.x ist jetzt erforderlich. Libevent wird jetzt über pkg-config erkannt.
  • Compilerwarnungen unter macOS und Windows beseitigt. Der Build auf diesen Plattformen sollte jetzt ohne Warnungen erfolgen.
  • Einige Warnungen von LLVM scan-build beseitigt.

PgBouncer 1.11.x

2019-08-27 - PgBouncer 1.11.0 - „Instinkt für Großes“

• Funktionen
  • Unterstützung für SCRAM-Authentifizierung für Clients und Server hinzugefügt. Der neue Authentifizierungstyp scram-sha-256 wurde ergänzt.
  • auth_type=password wird bei einem gespeicherten md5-Passwort so behandelt, wie es ein PostgreSQL-Server tun würde. (#129 )
  • Die Option log_stats hinzugefügt, um die Ausgabe von Statistiken ins Protokoll zu deaktivieren. (#287 )
  • Die Zeitzone zu Protokollzeitstempeln hinzugefügt.
  • Die PID im Protokollpräfix in [eckige Klammern] setzen.
• Fehlerbehebungen
  • Den OpenSSL-Test in configure bei neueren OpenSSL-Versionen mit -Werror korrigiert.
  • Die Berechnung der Wartezeit mit auth_user korrigiert. Sie führte entweder zu einem Absturz oder meldete unsinnige Werte für die Wartezeit. (#393 )
  • Das in PostgreSQL 12 hinzugefügte Paket GSSENCRequest verarbeiten. Es bewirkt derzeit nichts, verhindert aber verwirrende Fehlermeldungen zu “bad packet header”.
• Bereinigungen
  • Viele Verbesserungen in der Testsuite und mehrere neue Tests
  • Mehrere Compilerwarnungen unter Windows beseitigt.
  • Die Dokumentation des Abschnitts [users] erweitert und diesen zur Beispielkonfiguration hinzugefügt. (#330 )

PgBouncer 1.10.x

2019-07-01 - PgBouncer 1.10.0 - „Angst vor der Welt“

• Funktionen
  • Unterstützung für das Aktivieren und Deaktivieren von TLS 1.3 hinzugefügt. TLS 1.3 wurde abhängig von der OpenSSL-Bibliothek bereits unterstützt, wird jetzt aber auch von den Konfigurationseinstellungen zur Auswahl der TLS-Protokollversionen unterstützt.
• Fehlerbehebungen
  • Die Unterstützung für TLS 1.3 korrigiert. Sie funktionierte mit OpenSSL 1.1.1 und 1.1.1a nicht, wohl aber mit früheren und späteren Versionen.
  • Einen seltenen Absturz in SHOW FDS behoben (#311 ).
  • Ein Problem behoben, das bei vielen eintreffenden Abbruchanfragen zu einem längeren Ausfall führen konnte (#329 ).
  • “unexpected response from login query” nach dem Neuladen von Postgres vermieden (#220 ).
  • Die Berechnung von idle_transaction_timeout korrigiert (#125 ). Der Fehler führte in bestimmten Situationen zu vorzeitigen Zeitüberschreitungen.
• Bereinigungen
  • Verschiedene Protokoll- und Fehlermeldungen präzisiert.
  • Von Coverity erkannte Probleme behoben; keines hatte in der Praxis erhebliche Auswirkungen.
  • Alle Testskripte verbessert und dokumentiert.
  • Weitere SHOW-Befehle zur Dokumentation hinzugefügt.
  • Die Dokumentation von rst auf Markdown umgestellt.
  • Alle Python-Skripte im Quellbaum sind jetzt mit Python 3 kompatibel.

PgBouncer 1.9.x

2018-08-13 - PgBouncer 1.9.0 - „Überleben im Chaos“

• Funktionen
  • Befehl RECONNECT
  • Befehl WAIT_CLOSE
  • Schnelles Schließen: Ein Server im Sitzungs-Pooling-Modus wird sofort getrennt, wenn er sich im Modus “close_needed” (erneuter Verbindungsaufbau) befindet.
  • Die Spalte close_needed zu SHOW SERVERS hinzugefügt
• Fehlerbehebungen
  • Doppelte Speicherfreigabe in parse_filename vermieden
  • Dereferenzierung eines NULL-Zeigers in parse_line vermieden
• Bereinigungen
  • mkauth.py auf Python 3 portiert
  • Die Dokumentation der Signale verbessert
  • Die Dokumentation zum Schnelleinstieg verbessert
  • Den Befehl SET dokumentiert
  • Die Liste benötigter Software korrigiert
  • Warnungen zu -Wimplicit-fallthrough beseitigt
  • Fehlende Dokumentation für verschiedene SHOW-Felder ergänzt
  • Das Verhalten beim erneuten Verbindungsaufbau nach Neuladen und DNS-Änderungen dokumentiert
  • Dokumentiert, dass auf KILL anschließend RESUME folgen muss
  • Die Dokumentation von server_lifetime präzisiert
  • Tippfehler und Groß-/Kleinschreibung in Meldungen und Dokumentation korrigiert
  • Den psql-Aufruf in Tests korrigiert
  • Verschiedene weitere Verbesserungen am Testaufbau

PgBouncer 1.8.x

2017-12-20 - PgBouncer 1.8.1 - „Beim Bodenkampf aufs Zuschlagen setzen“

• Fehlerbehebungen
  • Die Datei include/pam.h in den Distributions-Tarball aufgenommen. Ihr Fehlen hatte jeglichen Build aus dem Tarball von 1.8 verhindert.

2017-12-19 - PgBouncer 1.8 - „Sicher am Steuer“

• Funktionen
  • PAM-Authentifizierung unterstützt. (Mit --with-pam aktivieren.)
  • Die Felder paused und disabled zur Ausgabe von SHOW DATABASES hinzugefügt.
  • Das Feld maxwait_us zur Ausgabe von SHOW POOLS hinzugefügt.
  • Die Felder wait und wait_us zur Ausgabe der SHOW-Befehle hinzugefügt.
  • Die neuen Befehle SHOW STATS_TOTALS und SHOW STATS_AVERAGES hinzugefügt.
  • Abfragen und Transaktionen werden in SHOW STATS getrennt erfasst. Die Felder total_requests, avg_req und avg_query wurden durch neue Felder ersetzt.
  • wait_time zu SHOW STATS hinzugefügt.
• Fehlerbehebungen
  • Die aktualisierte libusual unterstützt OpenSSL 1.1.
  • Es wird nicht versucht, TLS auf Unix-Sockets zu verwenden.
  • Beim Parsen von pg_hba.conf wird nach fehlerhaften Zeilen weitergearbeitet, statt die gesamte Datei zurückzuweisen. (#118 )
  • Mehrere weitere Korrekturen beim Parsen von hba.
  • Eine Race Condition beim Abbrechen einer Abfrage behoben. (#141 )
• Bereinigungen
  • Die Einstellung auth_user ist jetzt auch global zulässig, nicht nur pro Datenbank. (#142 )
  • Die Client- und Serverkodierung der Konsole auf UTF8 setzen.

PgBouncer 1.7.x

2016-02-26 - PgBouncer 1.7.2 - „Endlich abgehoben“

• Fehlerbehebungen
  • Absturz beim Entfernen einer veralteten PID-Datei behoben. Das Problem wurde in 1.7.1 eingeführt.
  • Speicherbereinigung deaktiviert: Sie verhindert die Übernahme und ist für produktive Lasten nicht sinnvoll. Das Problem wurde in 1.7.1 eingeführt.
  • Nach der Übernahme warten, bis die PID-Datei entfernt wurde, bevor der Start fortgesetzt wird. Das durch die Speicherbereinigung verlangsamte Herunterfahren legte eine bestehende Race Condition offen. (#113 )
• Bereinigungen
  • Builds durch Entfernen der DBGVER-Verarbeitung reproduzierbar gemacht. (#112 )
  • Antimake: Dateiliste aus $(wildcard) sortieren; neuere gmake-Versionen sortieren sie nicht mehr. (#111 )
  • libssl-Version im Protokoll anzeigen.
  • deb: Vollständige Härtung aktivieren.

2016-02-18 - PgBouncer 1.7.1 - „An fünf Freunde weiterleiten, sonst …“

WARNUNG: Seit Version 1.7 wird server_reset_query nicht ausgeführt, wenn sich die Datenbank im Transaktions-Pooling-Modus befindet. Offenbar wurde dies in der Ankündigung zu 1.7 nicht deutlich genug hervorgehoben. Falls Anwendungen darauf angewiesen sind, mit server_reset_query_always das bisherige Verhalten wiederherstellen.

Die Arbeit an dieser Version bestand ansonsten hauptsächlich darin, ein vermeintliches TLS-Speicherleck aufzuspüren, das sich als nicht existent erwies. Stattdessen benötigt der libssl-Build in Debian/wheezy 600k zusätzlichen Speicher pro Verbindung (ohne Speicherleck) statt der erwarteten 20-30k. Darauf sollte bei der Verwendung von TLS geachtet werden.

• Fehlerbehebungen
  • TLS: sslmode “disabled” in “disable” umbenannt, da PostgreSQL diese Bezeichnung verwendet.
  • TLS: client_tls_sslmode=verify-ca/-full weist jetzt Verbindungen ohne Clientzertifikat ab. (#104 )
  • TLS: client_tls_sslmode=allow/require validiert ein Clientzertifikat, wenn eines gesendet wird. Zuvor blieb die Zertifikatsvalidierung unkonfiguriert, sodass Verbindungen mit Clientzertifikat fehlschlugen. (#105 )
  • Speicherleck beim Freigeben einer Datenbank behoben.
  • Mögliches Speicherleck in tls_handshake() behoben.
  • EOF-Behandlung in tls_handshake() korrigiert.
  • Zu kleinen memset-Bereich in der Kompatibilitätsimplementierung von asn1_time_parse korrigiert.
  • Build ohne TLS (--without-openssl) korrigiert. (#101 )
  • Verschiedene Probleme beim Windows-Build behoben. (#100 )
• Bereinigungen
  • TLS: SSL_MODE_RELEASE_BUFFERS verwenden, um den Speicherverbrauch inaktiver Verbindungen zu verringern.
  • Zugewiesenen Speicher beim Beenden freigeben. Dies erleichtert den Einsatz von Werkzeugen zur Suche nach Speicherlecks.
  • Dokumentation zu server_reset_query verbessert. (#110 )
  • TLS-Optionen zur Beispielkonfiguration hinzugefügt.

2015-12-18 - PgBouncer 1.7 - „Die Farben variieren nach der Auferstehung“

• Funktionen
  • TLS-Verbindungen unterstützen. OpenSSL/LibreSSL dient als Backend-Implementierung.
  • Authentifizierung über TLS-Clientzertifikate unterstützen.
  • “peer”-Authentifizierung über Unix-Sockets unterstützen.
  • Eine Datei für die hostbasierte Zugriffskontrolle unterstützen, wie pg_hba.conf in PostgreSQL. Damit lassen sich TLS für Netzwerkverbindungen und “peer”- Authentifizierung für lokale Verbindungen konfigurieren.
• Bereinigungen
  • query_wait_timeout standardmäßig auf 120s setzen. Der bisherige Standardwert (0) führt zu unbegrenztem Warten in der Warteschlange, was nicht sinnvoll ist. Das bedeutet: Hat ein Client eine ausstehende Abfrage und wurde ihm noch keine Serververbindung zugewiesen, wird die Clientverbindung getrennt.
  • server_reset_query_always standardmäßig deaktivieren. Die Abfrage zum Zurücksetzen wird jetzt nur in Pools mit Sitzungs-Pooling verwendet.
  • pkt_buf auf 4096 Byte erhöhen. Dies verbessert die Leistung mit TLS. Das Verhalten hängt wahrscheinlich von der Last ab, die Änderung sollte jedoch unbedenklich sein, da die Paketpuffer seit v1.2 von den Verbindungen getrennt sind und erst bei Bedarf aus einem Pool bezogen werden.
  • Pipelining durch Zählen der erwarteten ReadyForQuery-Pakete unterstützen. Dadurch wird verhindert, dass der Server zu früh freigegeben wird. Behebt #52 .
  • sbuf_loopcnt-Logik verbessert: Der Socket wird garantiert erneut verarbeitet, auch wenn kein Socket-Ereignis vorliegt. Dies ist für TLS erforderlich, da es eigene Puffer verwendet.
  • Systemtests für aktuelle BSD- und MacOS-Versionen angepasst. (Eric Radman)
  • crypt-Authentifizierung entfernt. Sie ist veraltet und wird seit PostgreSQL 8.4 nicht mehr unterstützt.
  • Die einfache configure-Option “–with-cares” korrigiert: Ohne Argument funktionierte sie nicht.

PgBouncer 1.6.x

2015-09-03 - PgBouncer 1.6.1 - „Das Studiopublikum stimmt zu“

• Funktionen

  • Neue Einstellung: server_reset_query_always. Wenn sie gesetzt ist, wird server_reset_query für Pools ohne Sitzungs-Pooling deaktiviert. PgBouncer führt pool_mode pro Pool ein, doch Sitzungs-Pooling und Transaktions-Pooling sollten nicht dieselbe Abfrage zum Zurücksetzen verwenden. Tatsächlich sollte Transaktions-Pooling überhaupt keine solche Abfrage verwenden.

    In 1.6.x ist die Einstellung aktiviert, in 1.7 wird sie jedoch deaktiviert.

• Fehlerbehebungen

  • [SICHERHEIT] Ungültige Zuweisung von auth_user entfernt. (#69) Wenn auth_user gesetzt ist und der Client einen nicht vorhandenen Benutzernamen angibt, meldet sich der Client als auth_user an. Das ist problematisch.

    CVE-2015-6817

  • NoticeResponse in handle_auth_response überspringen. Andernfalls führen ausführliche Protokollierungsstufen auf dem Server zu Anmeldefehlern.

  • Konsole: auth_user belegen, wenn auth_type=any gesetzt ist. Andernfalls kann die Protokollierung abstürzen (#67).

  • Verschiedene Portabilitätskorrekturen (OpenBSD, Solaris, OSX).

2015-08-01 - PgBouncer 1.6 - „Zombies der Zukunft“

• Funktionen

  • Den Passwort-Hash des Benutzers aus einer PostgreSQL-Datenbank laden. Neue Parameter:

    auth_user Benutzer, mit dem die Verbindung zur selben Datenbank hergestellt und die Benutzerinformation abgefragt wird. Kann auch pro Datenbank gesetzt werden.

    auth_query SQL-Abfrage, die als auth_user ausgeführt wird. Standardwert: “SELECT usename, passwd FROM pg_shadow WHERE usename=$1”

    (Cody Cutrer)

  • Der Pooling-Modus lässt sich sowohl pro Datenbank als auch pro Benutzer konfigurieren. (Cody Cutrer)

  • Verbindungsgrenzen pro Datenbank und pro Benutzer: max_db_connections und max_user_connections. (Cody Cutrer / Pavel Stehule)

  • DISABLE/ENABLE-Befehle hinzugefügt, um neue Verbindungen zu verhindern. (William Grant)

  • Neues DNS-Backend: c-ares. Es ist das einzige DNS-Backend, das alle relevanten Funktionen unterstützt: /etc/hosts mit Aktualisierung, SOA-Abfragen, große Antworten (über TCP/EDNS+UDP), IPv6. Es ist jetzt das bevorzugte Backend und wird künftig wahrscheinlich das einzige Backend sein, da die Unterstützung einer Vielzahl unzureichender Bibliotheken nicht sinnvoll ist.

    Problem: c-ares-Versionen <= 1.10 enthalten einen Fehler, durch den die CNAME-Unterstützung bei aktiviertem IPv6 nicht funktioniert. (Im Upstream behoben.) Als Übergangslösung wird c-ares <= 1.10 nur mit IPv4 verwendet. PgBouncer wird die anderen Backends daher erst entfernen, wenn c-ares >1.10 (noch nicht veröffentlicht) einige Zeit verfügbar ist …

  • remote_pid in SHOW CLIENTS/SERVERS anzeigen. Verfügbar für Clients mit Verbindungen über Unix-Sockets sowie für Serververbindungen über TCP und Unix-Sockets. Bei TCP-Servern wird die PID aus dem Abbruchschlüssel entnommen.

  • Eigenen Konfigurationsparameter (dns_nxdomain_ttl) zur Steuerung der negativen DNS-Zwischenspeicherung hinzugefügt. (Cody Cutrer)

  • IP-Adresse und Port des Clienthosts zu application_name hinzufügen. Dies wird durch den Konfigurationsparameter application_name_add_host aktiviert, dessen Standardwert ‘off’ ist. (Andrew Dunstan)

  • Konfigurationsdateien unterstützen die Direktive ‘%include FILENAME’, mit der sich die Konfiguration auf mehrere Dateien aufteilen lässt. (Andrew Dunstan)

• Bereinigungen

  • Protokoll: IPv6-Adressen in [] einschließen.
  • Protokoll: Beim Verbindungsaufbau zum Server lokale IP-Adresse und Port anzeigen.
  • win32: Für lange Argumente den GNU-Stil verwenden: –foo
  • Ziffern in Hostnamen zulassen; immer versuchen, mit inet_pton zu parsen.
  • deallocate_all() in den FAQ korrigiert.
  • Falsches Schlüsselwort in der Beispielkonfiguration korrigiert. (Magnus Hagander)
  • Kommentare (mit ‘;’) in Authentifizierungsdateien zulassen. (Guillaume Aubert)
  • Rechtschreibfehler in Protokollmeldungen und Kommentaren korrigiert. (Dmitriy Olshevskiy)

• Fehlerbehebungen

  • Aufbau neuer Verbindungen während der Wartung korrigiert. (Cody Cutrer)
  • Authentifizierungsdatei beim Start nicht zweimal laden. (Cody Cutrer)
  • Korrekte Invalidierung automatisch erzeugter Datenbanken.
  • IPv6: IPV6_V6ONLY am lauschenden Socket setzen.
  • win32: SO_REUSEADDR am lauschenden Socket nicht setzen.
  • memcpy für IPv6-Adressen korrigiert.
  • Abbruch wartender Clients korrigiert. (Mathieu Fenniak)
  • Kleinen Fehler behoben: Das Ergebnis von calloc muss geprüft werden. (Heikki Linnakangas)
  • Zeilenumbruch am Ende der PID-Datei hinzugefügt. (Peter Eisentraut)
  • Keine neuen Serververbindungen zulassen, wenn PAUSE ausgeführt wurde. (Petr Jelinek)
  • ‘bad packet’ bei der Anmeldung behoben, wenn der Header verzögert eintrifft. (Michał Trojnara, Marko Kreen)
  • Von Coverity erkannte Fehler behoben. (Euler Taveira)
  • server_idle_timeout deaktivieren, wenn die Serveranzahl unter min_pool fällt (#60). (Marko Kreen)

PgBouncer 1.5.x

2015-04-09 - PgBouncer 1.5.5 - „Totstellen, um zu gewinnen“

• Fehlerbehebungen
  • Aus der Ferne auslösbaren Absturz behoben: Eine ungültige Paketreihenfolge führt zum Zugriff auf einen NULL-Zeiger. Nicht ausnutzbar, nur DoS.

2012-11-28 - PgBouncer 1.5.4 - „Keine Lecks, Töpfchentraining erfolgreich“

• Fehlerbehebungen
  • DNS: Speicherleck im getaddrinfo_a()-Backend behoben.
  • DNS: Speicherleck im udns-Backend behoben.
  • DNS: Statistikberechnung korrigiert.
  • DNS: Verarbeitung von Fehlermeldungen für getaddrinfo_a() verbessert.
  • win32-Kompilierung korrigiert.
  • Prüfung der Compiler-Unterstützung für Abhängigkeiten in configure korrigiert.
  • Einige Dokumentationsfehler korrigiert.

2012-09-12 - PgBouncer 1.5.3 - „Quantentoaster“

• Kritische Fehlerbehebung

  • Zu lange Datenbanknamen können zu einem Absturz führen, der sich bei aktivierten automatisch erzeugten Datenbanken aus der Ferne auslösen lässt.

    Die ursprünglichen Prüfungen gingen davon aus, dass alle Namen aus Konfigurationsdateien stammen; daher war die Verwendung von fatal() unproblematisch. Sind automatisch erzeugte Datenbanken jedoch aktiviert

    • durch ‘*’ im Abschnitt [databases] -, kann der Datenbankname aus dem Netzwerk stammen, was ein Beenden aus der Ferne ermöglicht.

    CVE-2012-4575

• Kleinere Funktionen

  • max_packet_size: Konfigurationsparameter zur Einstellung der maximalen Paketgröße, die weitergeleitet werden darf. Der Standardwert bleibt unverändert: (2G-1), kann jetzt jedoch verkleinert werden.
  • Wenn sich ein Paketheader nicht parsen lässt, diesen im Protokoll und in der Fehlermeldung hexadezimal anzeigen.

• Fehlerbehebungen

  • AntiMake verwendete $(relpath) und $(abspath) zur Bearbeitung von Pfadnamen. Dadurch schlug der Build jedoch fehl, wenn der Pfad des Quellbaums symbolische Links enthielt. Der Code arbeitet jetzt ausschließlich mit einfachen Zeichenketten.
  • Konsole: Mit SET können jetzt leere Zeichenketten als Werte gesetzt werden.
  • config.txt: Darauf hinweisen, dass alle Zeitüberschreitungen als Gleitkommazahlen angegeben werden können. Diese wenig bekannte Funktion wurde in 1.4 eingeführt.

2012-05-29 - PgBouncer 1.5.2 - „Nicht kauen, nur schlucken“

• Fehlerbehebungen
  • Durch einen Fehler wurde reserve_pool_timeout in Mikrosekunden statt Sekunden interpretiert. Dadurch wurde der Reservepool praktisch sofort aktiviert, sobald der Pool voll war. Jetzt wird der Wert wie vorgesehen als Sekunden interpretiert. (Von Keyur Govande bemerkt)

2012-04-17 - PgBouncer 1.5.1 - „Abbrechen, wiederholen, ignorieren?“

• Funktionen
  • Parameter zur Einstellung der Berechtigungen für den Unix-Socket: unix_socket_mode=0777, unix_socket_group=’’.
• Fehlerbehebungen
  • Leere Zeichenketten als serverseitige Variablenwerte zulassen. Dies ist erforderlich, damit “application_name” korrekt funktioniert, da es der einzige Parameter ohne serverseitigen Standardwert ist.
  • Bei geänderter Verbindungszeichenfolge die Aktualisierung der Serverparameter erzwingen. Zuvor verwendete PgBouncer die alten Parameter weiter, was bei einem PostgreSQL-Upgrade zu Problemen führt.
  • Bei geänderter Verbindungszeichenfolge einer automatisch erzeugten Datenbank alte Verbindungen trennen.
  • cf_setint: strtol() statt atoi() zum Parsen ganzzahliger Konfigurationsparameter verwenden. Damit sind hexadezimale und oktale Werte sowie eine bessere Fehlererkennung möglich.
  • sigqueue() verwenden, um das Vorhandensein von union sigval zu erkennen. Dies korrigiert die Kompilierung unter HPUX.
  • Den Befehl ‘git’ aus dem Makefile entfernen, da er bei Builds aus einem einfachen Tarball zufällige Fehler verursacht.
  • Parameter stats_period dokumentieren. Er steuert das Intervall für die Statistikausgabe.
  • Asciidoc >= 8.4 voraussetzen; die Dokumentation scheint nicht mehr mit früheren Versionen kompatibel zu sein.
  • Bei EINTR von close() keinen erneuten Versuch mehr unternehmen.

2012-01-05 - PgBouncer 1.5 - „Seit 2007 zufriedene Clients durchschleusen“

Wenn hinter einem DNS-Namen mehr als 8 IP-Adressen verwendet werden, muss die Abfrage jetzt über das EDNS0-Protokoll erfolgen. Nur die Backends getaddrinfo_a()/getaddrinfo() und UDNS unterstützen es, libevent 1.x/2.x nicht. Zur Aktivierung für libc ‘options edns0’ zu /etc/resolv.conf hinzufügen.

Zum Kompilieren wird GNU Make 3.81+ benötigt.

• Funktionen
  • Änderungen an DNS-Antworten erkennen und Verbindungen zu IP-Adressen invalidieren, die in der neuesten Antwort nicht mehr enthalten sind. (Petr Jelinek)
  • Hostnamen anhand der Seriennummer der DNS-Zone invalidieren. Wenn dns_zone_check_period gesetzt ist, werden die SOA-Einträge aller DNS-Zonen abgefragt. Hat sich die Seriennummer geändert, werden alle Hostnamen abgefragt. Dies ist für eine deterministische Invalidierung von Verbindungen erforderlich, da eine Invalidierung bei der Namensauflösung nutzlos ist, wenn keine Namensauflösung stattfindet. Funktioniert nur mit dem neuen UDNS-Backend.
  • Neue Befehle SHOW DNS_HOSTS und SHOW DNS_ZONES zum Untersuchen des DNS-Caches.
  • Neuer Parameter: min_pool_size verhindert, dass bei fehlender Last alle Verbindungen getrennt werden. (Filip Rembiałkowski)
  • idle_in_transaction_timeout: Transaktion beenden, wenn sie zu lange im Leerlauf ist. Standardmäßig nicht gesetzt.
  • Neues libudns-Backend für DNS-Abfragen. Bietet mehr Funktionen als evdns. Mit –with-udns aktivieren. Unterstützt IPv6 noch nicht.
  • KILL-Befehl zum sofortigen Trennen aller Verbindungen einer Datenbank. (Michael Tharp)
  • Wechsel zum Antimake-Build-System für übersichtlichere Makefiles. Zum Kompilieren wird jetzt GNU Make 3.81+ benötigt.
• Fehlerbehebungen
  • DNS funktioniert jetzt mit IPv6-Hostnamen.
  • Verbindungszustand nicht ändern, wenn NOTIFY vom Server eintrifft.
  • Verschiedene Dokumentationsfehler korrigiert. (Dan McGee)
  • Konsole: Bezeichner in "" einschließen können. Ursprünglich gab es keine Befehle mit Datenbanknamen als Argument, sodass kein Quoting benötigt wurde.
  • Konsole: Im regulären Ausdruck für Wörter auch Ziffern am Wortanfang zulassen. Ein strikter Parser würde die Verarbeitung hier zu komplex machen.
  • Pausierte automatisch erzeugte Datenbanken nicht verfallen lassen. (Michael Tharp)
  • Automatisch erzeugte Datenbanken bei PAUSE nach Bedarf anlegen. (Michael Tharp)
  • Falsche Protokollmeldung des Befehls RESUME korrigiert. (Peter Eisentraut)
  • Enthält die Datenbank-Verbindungszeichenfolge user= ohne password=, wird das Passwort aus userlist übernommen.
  • ‘*’ im Übernahmecode korrekt parsen.
  • autogen.sh: Mit älteren autoconf-/automake-Versionen funktionieren.
  • Absturz beim Betrieb als Dienst unter win32 behoben, der durch ein fehlerhaftes basename() der mingw/msvc-Laufzeit verursacht wurde. Jetzt wird immer die Kompatibilitätsimplementierung von basename() verwendet.

PgBouncer 1.4.x

2011-06-16 - PgBouncer 1.4.2 - „Algorithmus für den Erstschlag“

Betroffene Betriebssysteme: *BSD, Solaris, Win32.

• Portabilitätskorrekturen
  • CFLAGS an den Linker übergeben. Dies ist bei der pthread-basierten Ersatzimplementierung von getaddrinfo_a() erforderlich.
  • lib/find_modules.sh: split() durch index()+substr() ersetzen. Dadurch sollte es mit älteren AWKs funktionieren.
  • <usual/endian.h>: htoX/Xtoh-Definitionen des Systems ignorieren. Möglicherweise ist nur ein Teil der Makros definiert.
  • <usual/signal.h>: Kompatibilitätsimplementierungen von sigval und sigevent trennen.
  • <usual/socket.h>: <sys/uio.h> einbinden, um iovec zu erhalten.
  • <usual/time.h>: Automatische Funktionserkennung unter win32 verbessern.
  • <usual/base_win32.h>: Doppelte Deklaration von sigval/sigevent entfernen.

2011-04-01 - PgBouncer 1.4.1 - „Alles war nur gespielt“

• Funktionen

  • Lauschen und Verbindungsaufbau auf IPv6-Adressen unterstützen. (Hannu Krosing)
  • Mehrere Listen-Adressen in ’listen_addr’. Für jede wird getaddrinfo() aufgerufen, sodass auch Namen verwendet werden können.
  • Konsole: PgBouncer-Version als ‘server_version’ an den Client senden.

• Wichtige Fehlerbehebungen

  • getaddrinfo_a() unter glibc < 2.9 deaktivieren, da es mit älteren Versionen abstürzt.

    Insbesondere betroffene Betriebssysteme: RHEL/CentOS 5.x (glibc 2.5), Ubuntu 8.04 (glibc 2.7). Ebenfalls betroffen ist Debian/lenny (glibc 2.7), dessen getaddrinfo_a() zwar nicht abstürzt, für das es aber keine zuverlässige Erkennungsmöglichkeit gibt.

    Auf solchen Betriebssystemen bitte libevent 2.x verwenden; die Ersatzimplementierung von getaddrinfo_a() ist nicht für Produktionssysteme vorgesehen. Im neuen Abschnitt zur Unterstützung für DNS-Abfragen in README wird erläutert, wie das DNS-Backend ausgewählt wird.

    (Hubert Depesz Lubaczewski, Dominique Hermsdorff, David Sommerseth)

  • Bei Verwendung von libevent 2.x standardmäßig –enable-evdns aktivieren.

  • tcp_keepalive standardmäßig aktivieren, wie es auch PostgreSQL tut. (Hubert Depesz Lubaczewski)

  • server_reset_query standardmäßig auf DISCARD ALL setzen, um von Anfang an mit PostgreSQL kompatibel zu sein.

  • win32: Abstürze bei Unix-Socket-Adressen mit NULL behoben. (Hiroshi Saito)

  • Bereinigung automatisch erzeugter Datenbanken korrigiert: Der alte Code verwechselte Datenbanken und Pools. Sobald ein leerer Pool gefunden wurde, wurde die Datenbank als ‘idle’ markiert. Dadurch konnte später eine Datenbank mit aktiven Benutzern beendet werden.

    Gemeldet von: Hubert Depesz Lubaczewski

• Fehlerbehebungen

  • Kompatibilitätsimplementierung von getaddrinfo_a() durch einen einzelnen parallelen Thread für Namensabfragen nicht blockierend gemacht.
  • Kompilierung mit pthread aktivieren, wenn die Kompatibilitätsimplementierung von getaddrinfo_a verwendet wird.
  • release_server setzte bei einer Trennung aufgrund der Lebensdauer ->last_lifetime_disconnect nicht. (Emmanuel Courreges)
  • win32: Authentifizierungsdateien mit DOS-Zeilenenden korrigiert. load_file() berücksichtigte nicht, dass die Datei beim Laden schrumpft. (Rich Schaaf)
  • <usual/endian.h>: autoconf-Erkennung für enc/dec-Funktionen hinzufügen, um Konflikte unter BSD zu vermeiden. (James Pye)
  • Nicht abstürzen, wenn die Konfigurationsdatei nicht vorhanden ist. (Lou Picciano)
  • Bei fehlgeschlagener DNS-Abfrage mit sehr ausführlicher Protokollierung (-v -v) nicht abstürzen. (Hubert Depesz Lubaczewski, Dominique Hermsdorff)
  • In find_modules.sh Backticks statt $(cmd) verwenden, um die Portabilität zu verbessern. (Lou Picciano)
  • In find_modules.sh ‘awk’ statt ‘sed’ verwenden, um die Portabilität zu verbessern. (Giorgio Valoti)
  • Informationen zum aktiven asynchronen DNS-Backend beim Start protokollieren.
  • –disable-evdns korrigiert, sodass es ’no’ statt ‘yes’ bedeutet.
  • In der Dokumentation erwähnen, dass -R unix_socket_dir voraussetzt.
  • server_reset_query in faq.txt erläutern.
  • Verloren gegangenen memset im Slab-Allokator wiederhergestellt.
  • Verschiedene kleinere Portabilitätskorrekturen in libusual.

2011-01-11 - PgBouncer 1.4 - „Blutiger Code“

• Funktionen

  • Asynchrone DNS-Abfragen: Hostnamen werden jetzt beim Verbindungsaufbau statt beim Neuladen aufgelöst; die Zwischenspeicherung ist konfigurierbar. (Siehe Parameter dns_max_ttl.)

    Standardmäßig wird getaddrinfo_a() (glibc) als Backend verwendet. Ist es nicht vorhanden, wird getaddrinfo_a() durch blockierendes(!) getaddrinfo() emuliert.

    Mit dem Argument –enable-evdns für configure wird evdns von libevent als Backend verwendet. Es ist nicht standardmäßig aktiviert, da libevent 1.3/1.4 eine fehlerhafte Implementierung enthält. Nur evdns in libevent 2.0 scheint in Ordnung zu sein.

  • Neue Konfigurationsvariable: syslog_ident zur Einstellung des syslog-Namens.

  • Korrekte Unterstützung des Startparameters application_name.

  • Lange Befehlszeilenoptionen (Guillaume Lelarge)

  • Portabilitätskorrekturen für Solaris (Hubert Depesz Lubaczewski)

  • Neue Konfigurationsvariable: disable_pqexec. Damit lässt sich in Umgebungen mit sehr hohen Sicherheitsanforderungen das Simple Query Protocol deaktivieren. Dies erfordert Anwendungen, die ausschließlich das Extended Query Protocol verwenden.

  • PostgreSQL-Kompatibilität: Ist der Datenbankname im Startpaket leer, den Benutzernamen als Datenbanknamen verwenden.

• Fehlerbehebungen

  • Bei den Serverparametern DateStyle und TimeZone muss die Groß-/Kleinschreibung exakt stimmen.
  • Konsole: Serverparameter datetime, timezone und stdstr an den Client senden.

• Interne Bereinigungen

  • Bibliothek libusual für systemnahe Hilfsfunktionen verwenden.
  • Feste Längenbegrenzung für Serverparameter entfernen.

PgBouncer 1.3.x

2010-09-09 - PgBouncer 1.3.4 - „Der Bouncer hat immer recht“

• Fehlerbehebungen
  • Fail-Fast-Logik bereits beim Verbindungsaufbau anwenden. Bei einem Serverfehler erhalten Clients den Fehler somit schon beim Verbindungsaufbau.
  • Automatisch erzeugte Datenbanken beim Neuladen nicht zur Prüfung markieren. Andernfalls werden sie beendet, da sie nicht in der Konfiguration stehen.
  • Parameter application_name standardmäßig ignorieren. Dadurch müssen PostgreSQL-9.0-Benutzer ihn nicht selbst in ignore_startup_parameters= aufnehmen.
  • Quoting in pg_auth korrigiert. ‘' wird dort nicht verwendet.
  • Bessere Fehlerausgabe auf der Konsole; eingehende Abfrage dem Benutzer anzeigen.
  • Betriebssysteme (OpenBSD) unterstützen, bei denen tv_sec nicht vom Typ time_t ist.
  • Übermäßig viele Warnungen mit gcc 4.5 vermeiden.

2010-05-10 - PgBouncer 1.3.3 - „NSFW“

• Verbesserungen
  • Argument von listen(2) mit listen_backlog konfigurierbar machen. Dies ist auf Betriebssystemen nützlich, bei denen das zulässige Systemmaximum konfigurierbar ist.
  • Meldungen beim Trennen verbessern, damit sie den Benutzernamen oder Datenbanknamen nennen, der zum Fehlschlagen der Anmeldung geführt hat.
• Fehlerbehebungen
  • Die Logik für erneute Verbindungsversuche im Fail-Fast-Verfahren umgestellt. Die bisherige Logik war bei dauerhaft fehlerhaften Datenbanken oder Benutzern störend, da sie selbst dann neue Versuche unternahm, wenn sich keine Clients anmelden wollten.
  • Protokollierungsfunktionen behalten den bisherigen errno-Wert bei. Andernfalls kann sich PgBouncer bei höheren Protokollierungsstufen und Protokollierungsproblemen unerwartet verhalten.
  • Verschiedene Puffer für den Verbindungsstart vergrößert, um die umfangreicheren Startmeldungen von EDB verarbeiten zu können.
  • Startanfrage des V2-Protokolls erkennen und einen klaren Grund für die Trennung angeben.

2010-03-15 - PgBouncer 1.3.2 - „Bumerangkugel“

• Fehlerbehebungen

  • Neue Konfigurationsvariable ‘query_wait_timeout’. Erhält der Client innerhalb dieser Anzahl von Sekunden keine Serververbindung, wird seine Verbindung getrennt.

  • Ist keine Serververbindung im Pool vorhanden und schlug der letzte Verbindungsversuch fehl, Clientverbindungen nicht warten lassen, sondern sofort einen Fehler senden.

    Zusammen mit der vorherigen Korrektur verhindert dies unnötige Wartezeiten bei ausgefallenen Datenbanken.

  • libevent-Zustand in sbuf.c nachverfolgen, um doppelte event_del()-Aufrufe zu vermeiden. Obwohl dies normalerweise unbedenklich ist, scheint es nicht zu 100% zu funktionieren. Jetzt sollte jederzeit bekannt sein, ob der Aufruf bereits erfolgt ist.

  • Wartung während SUSPEND deaktivieren. Andernfalls könnte die alte PgBouncer-Instanz bei kurzen Zeitüberschreitungen nach der Übergabe noch einige Verbindungen schließen.

  • client_login_timeout auf Clients anwenden, die auf das Begrüßungspaket warten (erste Serververbindung). Andernfalls können sie unbegrenzt warten, sofern query_timeout nicht gesetzt ist.

  • win32: Schalter -U/-P zu -regservice hinzufügen, damit das Konto für die Ausführung des Dienstes gewählt werden kann. Die bisherige automatische Auswahl zwischen Local Service und Local System war nicht zuverlässig genug.

  • Konsole: \0 am Ende von Textspalten entfernen. Dies war schwer zu erkennen, da C-Clients damit zurechtkamen.

  • Dokumentation verbessert. (Greg Sabino Mullane)

  • Einige Protokollmeldungen zur Anmeldung präzisiert.

  • Protokollierungsstufe für vom Pooler gesendete Fehler (meist beim Trennen) von INFO auf WARNING ändern, da sie auf Probleme hinweisen.

  • Protokollmeldung für query_timeout in “query timeout” ändern.

2009-07-06 - PgBouncer 1.3.1 - „Jetzt vollständig konform mit den NSA-Überwachungsanforderungen“

• Fehlerbehebungen
  • Problem mit sbuf_loopcnt behoben, das Verbindungen blockieren konnte. Lag die Länge einer Abfrage oder eines Ergebnisses nahe einem Vielfachen von (pktlen*sbuf_loopcnt) [standardmäßig 10k], konnte die Verbindung auf weitere Daten warten, die nicht mehr eintreffen würden.
  • Datenbank-Neukonfiguration sofort wirksam machen. Bisher konnten alte Verbindungen nach SIGHUP wiederverwendet werden.
  • SHOW DATABASES korrigiert, das durch das Hinzufügen einer Spalte nicht mehr funktionierte.
  • Bei “auth_type=any” war der Konsolenzugriff deaktiviert, da PgBouncer den Benutzernamen verwarf. Korrektur: Bei “auth_type=any” jeden Benutzer als Administrator zur Konsole zulassen.
  • Fehlerhaftes CUSTOM_ALIGN-Makro korrigiert. Glücklicherweise wird es nicht verwendet, wenn das Betriebssystem bereits ALIGN definiert; daher scheint der Fehler praktisch nicht aufgetreten zu sein.
  • win32: WSAStartup() immer aufrufen, nicht nur im Daemon-Modus, da beim Parsen der Konfiguration Hostnamen aufgelöst werden sollen.
  • win32: Den Namen der Konfigurationsdatei in der Befehlszeile des Dienstes in Anführungszeichen einschließen, um Leerzeichen in Pfaden zu ermöglichen. Der Pfad der ausführbaren Datei scheint dies aufgrund einer win32-Besonderheit nicht zu benötigen.
  • STATS zur Ausgabe von SHOW HELP hinzufügen.
  • doc/usage.txt: Die Zeiteinheiten in Konsolenergebnissen sind Mikrosekunden, nicht Millisekunden.

2009-02-18 - PgBouncer 1.3 - „Neue Abschlusstechnik Ki-Smash“

• Funktionen

  • IANA hat Port 6432 als offiziellen Port für PgBouncer zugewiesen. Daher wurde die Standardportnummer auf 6432 geändert. Für bestehende Einzelanwender ist keine Änderung erforderlich. Bei der Verteilung von PgBouncer-Paketen bitte den Paketstandard auf den offiziellen Port ändern.

  • Dynamisches Anlegen von Datenbanken (David Galoyan)

    Jetzt lässt sich eine Datenbank mit dem Namen “*” definieren. Ihre Verbindungszeichenfolge wird dann für alle nicht definierten Datenbanken verwendet. Dies ist hauptsächlich für Test- und Entwicklungsumgebungen nützlich.

  • Windows-Unterstützung (Hiroshi Saito)

    PgBouncer läuft jetzt unter Windows 2000+. Der Aufruf über die Befehlszeile bleibt unverändert, allerdings sind weder der Daemon-Modus noch ein Online-Neustart möglich. Für den Betrieb als Dienst den Parameter service_name in der Konfiguration festlegen. Danach:

    > pgbouncer.exe config.ini -regservice
    > net start SERVICE_NAME
    

    Zum Beenden und Aufheben der Registrierung:

    > net stop SERVICE_NAME
    > pgbouncer.exe config.ini -unregservice
    

    Für das Windows-Ereignisprotokoll muss zunächst die Ereignis-DLL registriert werden:

    > regsvr32 pgbevent.dll
    

    Anschließend kann “syslog = 1” in der Konfiguration gesetzt werden.

• Kleinere Funktionen

  • Datenbanknamen in der Konfigurationsdatei können jetzt mit dem üblichen SQL-Quoting für Bezeichner angegeben werden, um Sonderzeichen in Datenbanknamen zuzulassen.

  • Neue Einstellungen: ‘reserve_pool_size’ und ‘reserve_pool_timeout’. Wenn Clients im Pool länger als ‘reserve_pool_timeout’ Sekunden gewartet haben, legt ‘reserve_pool_size’ fest, wie viele Verbindungen zum Pool hinzugefügt werden können. Der Wert kann mit der Verbindungsvariable ‘reserve_pool’ auch pro Pool gesetzt werden.

  • Neue Einstellung ‘sbuf_loopcnt’, um die für einen Socket aufgewendete Zeit zu begrenzen.

    Unter bestimmten Bedingungen, etwa auf einem SMP-Server mit lokalem PostgreSQL und schnellem Netzwerk, kann PgBouncer die recv()->send()-Schleife oft durchlaufen, ohne auf einer Seite zu blockieren. Dadurch warten jedoch andere Verbindungen lange. Für eine fairere Verarbeitung die Anzahl der recv()->send()-Durchläufe für einen Socket begrenzen. Wird die Grenze erreicht, mit der Verarbeitung anderer Sockets fortfahren. Die Verarbeitung dieses Sockets wird in der nächsten Ereignisschleife fortgesetzt.

    Dank an Alexander Schöcke für den Bericht und die Tests.

  • crypt()-Authentifizierung ist jetzt optional, da sie aus PostgreSQL entfernt wurde. Falls das Betriebssystem sie nicht bereitstellt, funktioniert PgBouncer auch ohne sie.

  • Millisekunden zu Zeitstempeln im Protokoll hinzufügen.

  • Alte MD5-Implementierung durch eine kompaktere ersetzen.

  • ISC-Lizenz um die Klarstellung der FSF ergänzen.

• Fehlerbehebungen

  • Meldet event_del() einen Fehler, die Bereinigung einfach fortsetzen. Zuvor versuchte PgBouncer den Aufruf erneut, falls ENOMEM die Ursache war. Dies führte jedoch zu endlos wiederholten Protokollmeldungen; offenbar kommt libevent damit nicht zurecht.

    Weshalb event_del() beim ersten Aufruf einen Fehler meldet, ist weiterhin unklar.

  • –enable-debug legt jetzt lediglich fest, ob Debug-Informationen aus der Binärdatei entfernt werden. Die Option beeinflusst -fomit-frame-pointer nicht mehr, da dies gefährlich ist.

  • Reihenfolge der Include-Dateien korrigiert, da andernfalls System-Includes vor den internen eingebunden werden konnten. Dies war bei der neuen Datei md5.h ein Problem.

  • Datei COPYRIGHT in .tgz aufnehmen …

PgBouncer 1.2.x

2008-08-08 - PgBouncer 1.2.3 - „Sorgfältig ausgewählte Bytes“

• Fehlerbehebungen
  • Nicht funktionierenden SO_ACCEPTFILTER-Code für BSDs deaktiviert.
  • Beispieldatei etc/userlist.txt in tgz aufnehmen.
  • Bei rekursiven Aufrufen ‘$(MAKE)’ statt ‘make’ verwenden. (Jørgen Austvik)
  • _GNU_SOURCE definieren, da glibc sonst unbrauchbar ist.
  • libevent 1.1 den Linktest bestehen lassen, damit später “1.3b+ needed” gemeldet werden kann.
  • Veraltete PID-Datei erkennen und entfernen.

Dank an Devrim GÜNDÜZ und Bjoern Metzdorf für Problemberichte und Tests.

2008-08-06 - PgBouncer 1.2.2 - „Spuckbeutel inbegriffen“

• Fehlerbehebungen
  • ‘drop_on_error’ entfernt; es war keine gute Idee. Die Einstellung wurde als Übergangslösung für das fehlerhafte Verhalten des Plancaches in PostgreSQL eingeführt, kann jedoch im üblichen Fall, dass bestimmte Abfragen immer einen Fehler zurückgeben, Schäden verursachen.

2008-08-04 - PgBouncer 1.2.1 - „Wasserdicht“

• Funktionen
  • Neuer Parameter ‘drop_on_error’: Wenn der Server einen Fehler meldet, wird die Verbindung nicht wiederverwendet, sondern getrennt, sobald der Client sie nicht mehr benötigt. Dies ist zum Aktualisieren des Plancaches erforderlich. Die automatische Aktualisierung funktioniert auch in 8.3 nicht. Der Standardwert ist 1.
• Fehlerbehebungen
  • SHOW SOCKETS/CLIENTS/SERVERS: Nicht abstürzen, wenn ein Socket keinen Puffer hat.
  • Endlosschleife bei SUSPEND behoben, wenn suspend_timeout ausgelöst wird.
• Kleinere Bereinigungen
  • <sys/uio.h> für ‘struct iovec’ verwenden.
  • Herunterfahren (durch SIGINT) bei RESUME/SIGUSR2 abbrechen, da es sonst beim nächsten PAUSE ausgelöst würde.
  • Korrekte Protokollmeldung, wenn ein Konsolenvorgang abgebrochen wird.

2008-07-29 - PgBouncer 1.2 - „Gewöhnliche Zauberflöte“

PgBouncer 1.2 benötigt jetzt libevent-Version 1.3b oder neuer. Ältere libevent-Versionen stürzen mit dem neuen Neustartcode ab.

• Funktionen

  • Befehlszeilenoption (-u) und Konfigurationsparameter (user=) für den Benutzerwechsel beim Start. Außerdem verweigert PgBouncer jetzt die Ausführung als root.

    (Jacob Coby)

  • Aussagekräftigere Hilfeausgabe (-h). (Jacob Coby)

  • Neue Datenbankoption: connect_query ermöglicht eine Abfrage auf neuen Verbindungen, bevor diese verwendet werden.

    (Teodor Sigaev)

  • Neue Konfigurationsvariable ‘ignore_startup_parameters’, mit der zusätzliche Parameter im Startpaket zugelassen und ignoriert werden können. Standardmäßig sind nur ‘database’ und ‘user’ zulässig; alle anderen führen zu einem Fehler. Dies ist erforderlich, um übermäßig eifriges JDBC zu tolerieren, das ’extra_float_digits=2’ bedingungslos im Startpaket setzen möchte.

  • Protokollierung über syslog: neue Parameter syslog=0/1 und syslog_facility=daemon/user/local0.

  • Weniger riskanter Online-Neustart (-R)

    • Laden der FD vor fork ausführen, damit die Ausgabe auf der Konsole erfolgt und der Vorgang mit ^C abgebrochen werden kann.

    • SHUTDOWN nach fork belassen, damit ^C unbedenklich ist.

    • Ein connect() auf den Unix-Socket prüft, ob dort ein Prozess lauscht. Jetzt kann -R auch verwendet werden, wenn zuvor kein Prozess lief. Läuft bereits ein Prozess, wird aber -R nicht verwendet, schlägt der Start fehl.

  • Neue Konsolenbefehle:

    • SHOW TOTALS zeigt die Statistikzusammenfassung wie im Protokoll sowie den Speicherverbrauch.

    • SHOW ACTIVE_SOCKETS: Wie show sockets, jedoch auf aktive Sockets beschränkt.

• Weniger sichtbare Funktionen

  • suspend_timeout: Blockierte Verbindungen und langwierige Anmeldungen abbrechen. Dies erhöht die Sicherheit bei Neustarts.

  • Clients benachrichtigen, wenn die entfernte Datenbank bei der Anmeldung einen Fehler meldet.

  • Eine Datenbank aus der Konfiguration zu entfernen und neu zu laden funktioniert: Alle Verbindungen werden getrennt und die Datenbank wird entfernt.

  • Bei den Konsolenbefehlen SHOW/SET einige Parameter nachbilden, um PostgreSQL ähnlicher zu sein. Dies war erforderlich, damit psycopg eine Verbindung zur Konsole herstellen kann. (client_encoding/default_transaction_isolation/datestyle/timezone)

  • Mit server_lifetime=0 die Serververbindung sofort nach der ersten Verwendung trennen. Zuvor bewirkte “0”, dass PgBouncer das Alter des Servers ignorierte. Da dieses Verhalten nicht dokumentiert war, sollte niemand darauf angewiesen sein.

  • Interne Verbesserungen:

    • Paketpuffer werden erst bei Bedarf zugewiesen und wiederverwendet. Dies sollte den Speicherverbrauch erheblich senken. Damit wird es auch praktikabel, bei vielen Verbindungen große pktbuf zu verwenden.

    • Zahlreiche Verbesserungen bei der Fehlerbehandlung. PgBouncer sollte OOM-Situationen jetzt geordnet bewältigen.

    • Slab-Allokator für die Speicherverwaltung verwenden.

    • Zahlreiche Codebereinigungen.

• Fehlerbehebungen

  • Bisher wurde pro Ereignisschleife nur ein accept() ausgeführt. Bei vielen Verbindungsversuchen konnte sich dadurch ein Rückstau aufbauen. Jetzt werden vom lauschenden Socket immer alle ausstehenden Verbindungen angenommen, was das Problem beheben sollte.
  • EINTR von connect() behandeln.
  • configure.ac mit autoconf 2.59 kompatibel machen.
  • Kompatibilitätskorrekturen für Solaris (Magne Mæhre)

PgBouncer 1.1.x

2007-12-10 - PgBouncer 1.1.2 - „Der Hammer“

• Funktionen
  • Verbindungstrennungen aufgrund von server_lifetime erfolgen jetzt im Abstand von (server_lifetime / pool_size) Sekunden. Dadurch löst PgBouncer keine Flut von Neuverbindungen aus.
• Fehlerbehebungen
  • Probleme beim Online-Upgrade von 1.0 -> 1.1:
    • 1.0 verfolgt Serverparameter nicht nach, sodass sie NULL bleiben. 1.1 rechnete damit jedoch nicht und stürzte ab.
    • Sind Serverparameter unbekannt, aber entsprechende Clientparameter gesetzt, ein SET dafür ausführen, statt einen Fehler zu melden.
  • Vorübergehende Debug-Anweisungen entfernt, die versehentlich auf Stufe INFO im Code verblieben waren und die Protokolle füllten.
  • debian/changelog repariert.
• Bereinigung
  • Felder von struct SBuf für eine bessere Ausrichtung des Puffers neu anordnen.

2007-10-26 - PgBouncer 1.1.1 - „Breakdance-Biene“

• Fehlerbehebungen
  • Der Cache für Serverparameter konnte uninitialisiert bleiben, wodurch unnötige SET-Anweisungen ausgeführt wurden. Dies führte unter 8.1 zu Problemen, da standard_conforming_strings dort nicht verändert werden darf. (Dank an Dimitri Fontaine für Bericht und Tests.)
  • Einige Dokumentationsfehler korrigiert.
  • doc/fixman.py in .tgz aufnehmen.

2007-10-09 - PgBouncer 1.1 - „Werkzeugkasten mit verrücktem Hut“

• Funktionen

  • Folgende Serverparameter nachverfolgen:

    client_encoding  datestyle, timezone, standard_conforming_strings
    

  • Erweiterungen der Datenbank-Verbindungszeichenfolge:

    • Hostnamen in host= akzeptieren.
    • Benutzerdefinierten Unix-Socket-Pfad in host= akzeptieren.
    • Werte in Anführungszeichen akzeptieren: password=’ asd’‘foo’

  • Neue Konfigurationsvariable: server_reset_query wird unmittelbar nach der Freigabe gesendet.

  • Neue Konfigurationsvariable: server_round_robin zum Umschalten zwischen LIFO und RR.

  • Ein Abbruchpaket für eine inaktive Verbindung trennt diese nicht mehr.

  • Abbruch mit ^C aus psql funktioniert für SUSPEND / PAUSE.

  • FD-Grenzen beim Start ausgeben.

  • Beim Suspendieren möglichst schnell eine Paketgrenze erreichen.

  • ’timezone’ zu den Datenbankparametern hinzufügen.

  • Dateideskriptor der Protokolldatei dauerhaft offen halten. Er wird bei SIGHUP / RELOAD erneut geöffnet.

  • Informationen zum lokalen Verbindungsendpunkt in SHOW SERVERS/CLIENTS/SOCKETS.

• Codebereinigung

  • Mehr Debug-Protokollmeldungen enthalten Socket-Informationen.
  • Magische Zahlen entfernt und Fehlermeldungen bereinigt. (David Fetter)
  • Wrapper-Struktur für Informationen zum aktuellen Paket. Dies verringert die Komplexität erheblich.

• Fehlerbehebungen

  • Ungültige Paketheader besser erkennen.
  • Die Prüfung auf Änderungen an auth_file war fehlerhaft, wodurch PgBouncer die Datei zu häufig neu lud.

PgBouncer 1.0.x

2007-06-18 - PgBouncer 1.0.8 - „Jutsu der untoten Schaufel“

• Fehlerbehebungen
  • Absturz bei der Verarbeitung von Abbruchpaketen behoben. (^C aus psql)
• Funktionen
  • PAUSE ; RESUME ; funktioniert jetzt.
  • Parsing der Konsolenbefehle bereinigt.
  • Aufwendige Assertion-Prüfung auf Listenzugehörigkeit deaktiviert.

2007-04-19 - PgBouncer 1.0.7 - „Mit Vitamin A-Z“

• Fehlerbehebungen
  • Mehrere Fehler-/Hinweispakete, zwischen denen send() blockierte, lösten eine Assertion aus. Durch vollständiges Entfernen der Flush-Logik behoben. Da PgBouncer selbst nichts aktiv puffert, ist sie nicht erforderlich. Sie stammte noch aus der Zeit, als die Pufferung mit MSG_MORE in den Kernel verlagert wurde.
  • Außerdem vermeiden, die recv()-Logik aufzurufen, wenn das Senden nicht mehr blockiert.
  • Der Listensuchcode für admin_users und stats_users behandelte Teiltreffer falsch. Dies wurde korrigiert.
  • Ermittlung der UID des Unix-Socket-Peers auf getpeereid() vereinheitlicht.

2007-04-12 - PgBouncer 1.0.6 - „Tägliche Dosis“

• Fehlerbehebungen
  • Die Korrektur zur Deaktivierung der Wartung während der Übernahme konnte die Wartung vollständig deaktivieren. Dies wurde behoben.
  • Kompilierung unter FreeBSD korrigiert: <sys/ucred.h> benötigt dort <sys/param.h>. Dank an Robert Gogolok für den Bericht.

2007-04-11 - PgBouncer 1.0.5 - „Genug für heute“

• Fehlerbehebungen
  • Fehler beim Online-Neustart behoben:
    • ->ready für inaktive Server setzen.
    • Veralteten Code aus use_client_socket() entfernen.
    • Wartung während der Übernahme deaktivieren.

2007-04-11 - PgBouncer 1.0.4 - „Der letzte ‚letzte‘ Fehler“

• Fehlerbehebungen
  • Ein Hinweis von einem inaktiven Server markierte diesen als nicht bereinigt. release_server() rechnete damit nicht. Das Problem wurde durch Verwerfen behoben.

2007-04-11 - PgBouncer 1.0.3 - „Furchtloser Fork“

• Fehlerbehebungen

  • Im Anmeldepfad fehlte teilweise die Fehlerbehandlung, sodass eine dort abbrechende Verbindung Assertions auslösen konnte.
  • Assertions in sbuf.c bereinigt, um Probleme früher zu erkennen.
  • Core-Dump erzeugen, wenn Assert() auslöst.

• Neuerungen

  • Neue Konfigurationsvariablen: log_connections, log_disconnections, log_pooler_errors zum Ein- und Ausschalten ausführlicher Protokollausgaben.
  • Konfigurationsvariable: client_login_timeout zum Trennen nicht mehr reagierender Verbindungen während der Anmeldung, die SUSPEND und damit den Online-Neustart blockieren könnten.

2007-03-28 - PgBouncer 1.0.2 - „Überschalllöffel“

• Fehlerbehebungen
  • libevent kann innerhalb derselben Schleife ein bereits gelöschtes Ereignis melden. Die Wiederverwendung des Sockets für einen Schleifendurchlauf verhindern.
  • release_server() aus disconnect_client() prüfte nicht, ob das Paket tatsächlich gesendet worden war.

2007-03-15 - PgBouncer 1.0.1 - „Außerirdische Technologie“

• Fehlerbehebungen

  • Die gemischte Verwendung zwischengespeicherter und nicht zwischengespeicherter Zeitwerte sowie ein vorzeichenloser usec_t-typedef führten zu unbegründeten query_timeout-Fehlern.
  • Seltenen Fall behoben, bei dem ein Socket nach dem Aufwecken aus dem Warten auf das Senden blockiert bleiben konnte.
  • Fairere Warteschlangen für Serververbindungen. Zuvor konnte eine neue Abfrage vor einer älteren eine Serververbindung erhalten.
  • Freigabe des Servers verzögern, bis garantiert alles gesendet wurde.

• Funktionen

  • Befehl SHOW SOCKETS für detaillierte Zustandsinformationen.
  • PgSocket-Zeiger ins Protokoll aufnehmen, um einzelne Verbindungen leichter nachzuverfolgen.
  • In der Konsole SELECT anstelle von SHOW zulassen.
  • Verschiedene Codebereinigungen.

2007-03-13 - PgBouncer 1.0 - „Getunter BMW“

• Erste öffentliche Version.

7 - Community

Tutorials

• So konfigurieren Sie PgBouncer für Postgres Plus Standard Server

  Gute Übersicht über PgBouncer-Konzepte.

• Wozu dient das „Bouncing“?

  Beschreibt die Unterschiede zwischen den Pooling-Modi.

Support

• Projektseite auf GitHub

• Issue-Tracker auf GitHub

• PgBouncer-Themenbereich auf Stack Overflow

• Chatraum auf Gitter

• Community-Diskussionen auf GitHub

8 - Häufig gestellte Fragen

Wie stelle ich eine Verbindung zu PgBouncer her?

PgBouncer verhält sich wie ein PostgreSQL-Server. Richten Sie Ihren Client daher einfach auf den PgBouncer-Port.

Wie lassen sich Abfragen auf mehrere Server verteilen?

PgBouncer unterstützt eine durch Kommas getrennte Liste von Hosts in der Datenbank-Verbindungszeichenfolge. Mit load_balance_hosts=round-robin werden neue Serververbindungen reihum auf diese Hosts verteilt. Beispiel:

[databases]
app = host=pg1,pg2 port=5432 dbname=app load_balance_hosts=round-robin

Auch externe Werkzeuge können verwendet werden:

1. DNS-Round-Robin. Hinterlegen Sie mehrere IP-Adressen für einen DNS-Namen. PgBouncer führt nicht bei jeder neuen Verbindung eine DNS-Abfrage durch. Stattdessen speichert es alle IP-Adressen im Cache und verteilt die Verbindungen intern per Round-Robin. Hinweis: Sind einem Namen mehr als 8 IP-Adressen zugeordnet, muss das DNS-Backend das EDNS0-Protokoll unterstützen. Einzelheiten finden sich unter Unterstützung für DNS-Abfragen .

2. Verwenden Sie einen Load-Balancer für TCP-Verbindungen. Sowohl LVS als auch HAProxy scheinen dafür gut geeignet. Auf PgBouncer-Seite kann es sinnvoll sein, server_lifetime zu verkürzen und server_round_robin zu aktivieren: Standardmäßig werden inaktive Verbindungen nach dem LIFO-Prinzip wiederverwendet, was bei Lastverteilung ungünstig sein kann.

Wie lässt sich ein Failover durchführen?

Bei einer durch Kommas getrennten Hostliste und load_balance_hosts=disable verwendet PgBouncer denselben Host weiter, bis ein Verbindungsversuch scheitert. Dann versucht es den nächsten Host. Dabei werden die Rollen Primärserver und Replikat nicht erkannt. Für ein Failover, das Änderungen an der Datenbanktopologie folgt, sind externe Werkzeuge zu verwenden:

1. DNS-Neukonfiguration: Wenn die IP-Adresse geändert wird, auf die ein DNS-Name verweist, verbindet sich PgBouncer erneut mit dem neuen Server. Dieses Verhalten lässt sich über zwei Konfigurationsparameter steuern: dns_max_ttl legt die Gültigkeitsdauer eines Hostnamens fest; dns_zone_check_period bestimmt, wie häufig der SOA-Eintrag einer Zone auf Änderungen geprüft wird. Hat sich der SOA-Eintrag geändert, fragt PgBouncer alle Hostnamen dieser Zone erneut ab.

2. Tragen Sie einen neuen Host in die Konfiguration ein und lassen Sie PgBouncer sie neu laden: Senden Sie SIGHUP oder verwenden Sie den Befehl RELOAD in der Konsole. PgBouncer erkennt die geänderte Hostkonfiguration und verbindet sich mit dem neuen Server.

3. Verwenden Sie den Befehl RECONNECT. Er ist für Situationen vorgesehen, in denen sich keine der beiden vorherigen Optionen anwenden lässt, etwa wenn Sie den zuvor erwähnten HAProxy-Load-Balancer einsetzen, um Verbindungen hinter PgBouncer weiterzuleiten. RECONNECT öffnet einfach alle Serververbindungen neu. Führen Sie den Befehl aus, nachdem die andere Komponente ihre Routinginformationen geändert hat.

Wie lassen sich vorbereitete Anweisungen mit Sitzungs-Pooling verwenden?

Im Sitzungs-Pooling muss die Abfrage zum Zurücksetzen alte vorbereitete Anweisungen bereinigen. Hierzu kann server_reset_query = DISCARD ALL; oder zumindest DEALLOCATE ALL; verwendet werden.

Wie lassen sich vorbereitete Anweisungen mit Transaktions-Pooling verwenden?

Seit Version 1.21.0 kann PgBouncer vorbereitete Anweisungen im Transaktions-Pooling nachverfolgen und sicherstellen, dass sie bei Bedarf auf der zugeordneten Serververbindung vorbereitet werden. Um diese Funktion zu aktivieren, muss max_prepared_statements auf einen von null verschiedenen Wert gesetzt werden (der Standardwert ist 200). Weitere Einzelheiten finden Sie in der Dokumentation zu max_prepared_statements .

Je nach verwendeter Version kann PHP/PDO mit der Unterstützung vorbereiteter Anweisungen durch PgBouncer inkompatibel sein (#991 ). PHP/PDO ist nur bei Verwendung von PHP 8.4+ und libpq 17 kompatibel. Für Installationen mit älteren Versionen empfiehlt sich daher ein Upgrade oder die Deaktivierung vorbereiteter Anweisungen auf Clientseite.

Vorbereitete Anweisungen in JDBC deaktivieren

Die richtige Vorgehensweise für JDBC besteht darin, den Parameter prepareThreshold=0 zur Verbindungszeichenfolge hinzuzufügen.

Vorbereitete Anweisungen in PHP/PDO deaktivieren

Um serverseitig vorbereitete Anweisungen zu deaktivieren, muss das PDO-Attribut PDO::ATTR_EMULATE_PREPARES auf true gesetzt werden, entweder beim Verbindungsaufbau:

$db = new PDO("dsn", "user", "pass", array(PDO::ATTR_EMULATE_PREPARES => true));

oder später:

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

Wie aktualisiere ich PgBouncer, ohne Verbindungen zu unterbrechen?

Sie können einen rollierenden Neustart nach dem Verfahren im Dokumentationsabschnitt zu SHUTDOWN WAIT_FOR_CLIENTS durchführen.

Wie finde ich heraus, welcher Client welcher Serververbindung zugeordnet ist?

Verwenden Sie die Befehle SHOW CLIENTS und SHOW SERVERS in der Konsole.

1. Ordnen Sie mithilfe von ptr und link eine lokale Clientverbindung der Serververbindung zu.

2. Identifizieren Sie die vom Client ausgehende TCP-Verbindung anhand von addr und port der Clientverbindung.

3. Identifizieren Sie die zum Server führende TCP-Verbindung anhand von local_addr und local_port.

Soll PgBouncer auf dem Webserver oder dem Datenbankserver installiert werden?

Das hängt davon ab.

Eine Installation von PgBouncer auf dem Webserver ist sinnvoll, wenn kurzlebige Verbindungen genutzt werden, weil sie die Latenz beim Verbindungsaufbau minimiert. (TCP benötigt mehrere Paketumlaufzeiten, bevor eine Verbindung nutzbar ist.) Eine Installation von PgBouncer auf dem Datenbankserver eignet sich, wenn viele unterschiedliche Hosts (z. B. Webserver) darauf zugreifen. Ihre Verbindungen können dann gemeinsam optimiert werden.

PgBouncer kann sowohl auf dem Webserver als auch auf dem Datenbankserver installiert werden. Nachteilig ist, dass jeder zusätzliche PgBouncer-Hop jeder Abfrage eine geringe Latenz hinzufügt.

Letztlich müssen Sie testen, welches Modell Ihre Leistungsanforderungen am besten erfüllt. Sie sollten außerdem berücksichtigen, wie sich die gewählte PgBouncer-Position auf das Failover Ihrer Anwendungen auswirkt, wenn ein Webserver beziehungsweise der Datenbankserver ausfällt.