PostgreSQL 16 erweitert die Konfiguration und lernt neue Funktionen

PostgreSQL 16 ist nach rund 15 Monaten Entwicklungszeit erschienen. Diese Version bringt Neuerungen bei der Konfiguration, der Authentifizierung und dem Zusammenspiel mit JSON. Vor dem Upgrade muss der ein oder andere jedoch auch seine Hausaufgaben machen.

Reguläre Ausdrücke in der Konfiguration

In der für die Client-Authentifizierung zuständigen Konfigurationsdatei pg_hba.conf (und in pg_ident.conf) kann man den Namen der Datenbank und der Rolle jetzt als Regex angeben. Das ermöglicht komplexe Konfigurationen, speziell in Umgebungen, in denen viele Anwendungen oder Benutzer beispielsweise in LDAP automatisiert verwaltet werden.

# TYPE  DATABASE                USER                    METHOD
  host  "/^anwendung\d{1,6}$"   "/^benutzer\d{1,6}$"    scram-sha-256

Des Weiteren können Admins über diese Option Usern mehr als eine Datenbank zuweisen, ohne umständlich die Authentifizierung zu erweitern. Im folgenden Beispiel darf die Rolle andreas sich in jede Datenbank einloggen, deren Name mit andreas beginnt und von einer bis sechs Zahlen gefolgt ist. Das eignet sich unter anderen für das Zusammenspiel mit Entwicklungsumgebungen:

# TYPE  DATABASE                USER                    METHOD
host    "/^andreas\d{1,6}$"     andreas                 scram-sha-256

Vor PostgreSQL 16 musste man die Namen aller Datenbanken entweder einzeln oder kommasepariert auflisten oder sie einzeln in eine separate Datei schreiben.

Eingebundene Dateien in der Konfiguration

Neuerdings lassen sich zudem in pg_hba.conf und pg_ident.conf Dateien einbinden. Bisher war es lediglich möglich, für Rollen und Datenbanken eine Liste mit den Einträgen anzugeben, aber nicht möglich, Teile der Konfiguration in separate Dateien auszulagern. Daher mussten im Zusammenspiel mit Automatisierungswerkzeugen die Einträge in pg_hba.conf jeweils in der richtigen Reihenfolge enthalten sein, was umständliche Regex-Operationen nach sich zog oder komplexe Templates erforderte.

Mit include, include_if_exists und include_dir lässt sich die Konfiguration für pg_hba.conf nun sauber in einzelne Dateien verteilen und getrennt verwalten.

include /pfad/zur/config/pg_hba_dev.conf​

Wenn die in der include-Option angegebene Datei nicht existiert, spuckt PostgreSQL eine Fehlermeldung aus. Das stellt sicher, dass alle Dateien existieren. Der Befehl include_if_exists liest Dateien ein, sofern sie vorhanden sind. Andernfalls gibt es einen Logeintrag, aber keine Fehlermeldung. Schließlich liest include_dir alle Dateien in einem Verzeichnis ein, die auf *.conf enden und nicht mit einem Punkt beginnen.

Für alle drei Optionen gilt: Die Inhalte der Datei(en) werden an der Stelle der include*-Option eingesetzt. Da die Reihenfolge in der pg_hba.conf wichtig für die Authentifizierung ist, müssen Admins also weiterhin auf die passende Stelle achten. Ebenfalls ist die Benennung der Konfigurationsdateien in einem Verzeichnis wichtig, da PostgreSQL sie alphabetisch sortiert einliest.

Methoden zur Authentifizierung

Jeder Client, der libpq verwendet, kann neuerdings angeben, welche Authentifizierungsmethoden zugelassen oder verboten sind. Bisher konnte nur der Server die Methoden vorgeben. Wenn der Client eine Liste an Methoden schickt und der Server keine davon akzeptiert, findet kein Authentifizierungsversuch statt. Damit lässt sich verhindern, dass der Server eine unsichere Methode verwendet. Folgende Angabe schließt die Authentifizierung mittels Klartextpasswörtern und MD5-gehashten Passwörtern explizit aus.

require_auth=!password,!md5

Folgende Zeile lässt die Authentifizierung ausschließlich über Salted Challenge Response Authentication Mechanism (SCRAM) zu. Sollte der Server diese Methode nicht unterstützen, kommt keine Verbindung zustande.

require_auth=scram-sha-256

Load Balancing in libpq

Eine weitere Neuerung in libpq ist das eingebaute Load Balancing über unterschiedlich konfigurierte Datenbankverbindungen. Seit PostgreSQL 10 kann man mehr als eine Verbindung konfigurieren, die libpq der Reihe nach durchprobiert hat, bis eine Verbindung funktioniert. Das hat in Folge die Last der Anfragen auf die erste(n) Einträge in dieser Liste verteilt.

Mit load_balance_hosts=random kann libpq die Einträge in der Liste zufällig sortieren und einen davon auswählen. Das verteilt die Last gleichmäßig auf alle Server. Die Option load_balance_hosts kennt neben random die Angabe disable, die die zufällige Verteilung deaktiviert und immer die erste verfügbare Verbindung verwendet.

Die Option ist in PostgreSQL nur sinnvoll, wenn man lesende Anfragen auf Replicas verteilt. Schreibende Anfragen müssen weiterhin zum Primary gehen.

Der passende Systemuser

Das im SQL-Standard definierte SYSTEM_USER ist jetzt auch in PostgreSQL verfügbar. Es zeigt an, welcher System-User mit welcher Authentifizierungsmethode für die Verbindung eingesetzt wurde:

postgres=# SELECT CURRENT_USER, SYSTEM_USER;
 current_user | system_user
--------------+-------------
 andreas      | peer:ads

Die aktuell eingeloggte Rolle ist andreas, und die Verbindung kam vom Systemuser ads. Das Log-in erfolgte mit peer-Authentifizierung. Diese Information ist für Audit-Zwecke hilfreich, um nachzuvollziehen, wer sich in die Datenbank eingeloggt hat.