Zum Inhalt springen

Funktionen

PgBouncer-Funktionen — Pooling-Modi und SQL-Kompatibilität

  • 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.

Funktion Sitzungs-Pooling Transaktions-Pooling
Startparameter 1 Ja Ja
SET/RESET Ja Für nachverfolgte Parameter 1
LISTEN Ja Nie
NOTIFY Ja Ja
WITHOUT HOLD CURSOR Ja Ja
WITH HOLD CURSOR Ja Nie
Auf Protokollebene vorbereitete Ausführungspläne Ja Ja 2
PREPARE / DEALLOCATE Ja Nie
Temporäre Tabellen mit ON COMMIT DROP Ja Ja
Temporäre Tabellen mit PRESERVE/DELETE ROWS Ja Nie
Zurücksetzen zwischengespeicherter Pläne Ja Ja
LOAD-Anweisung Ja Nie
Advisory Locks auf Sitzungsebene Ja Nie

  1. Seit 1.26.0 verfolgt PgBouncer alle vom Server gemeldeten Parameter nach, die Clients ändern können: application_name, client_encoding, DateStyle, default_transaction_read_only (PostgreSQL 14+), IntervalStyle, scram_iterations (PostgreSQL 16+), search_path (PostgreSQL 18+), session_authorization, standard_conforming_strings und TimeZone. Bei Parametern, die der Server nicht meldet, werden nur die Startwerte nachverfolgt; spätere Änderungen durch SET werden nicht nachverfolgt. Einzelheiten und Hinweise zu Parametern von Erweiterungen finden sich unter track_extra_parameters und ignore_startup_parameters . ↩︎ ↩︎

  2. Die Unterstützung vorbereiteter Anweisungen auf Protokollebene ist aktiviert, wenn max_prepared_statements ungleich null ist. Der Standardwert ist 200; der Wert 0 deaktiviert diese Unterstützung. PREPARE / DEALLOCATE auf SQL-Ebene bleibt mit Transaktions-Pooling inkompatibel; ausgenommen sind DEALLOCATE ALL und DISCARD ALL bei aktivierter Nachverfolgung. ↩︎

Zuletzt geändert October 14, 2026 · Finalize multilingual documentation at doc.pg.center (91cb834)
Bearbeitet nach PgBouncer documentation (v1.26.0), Copyright (c) 2007-2009 Marko Kreen, Skype Technologies OÜ, lizenziert unter ISC License. Siehe Quellenangaben und Änderungsverlauf.