PostgreSQL 16 erweitert die Konfiguration und lernt neue Funktionen
Die Datenbank erlaubt reguläre Ausdrücke in Konfigurationsdateien und bekommt neue Funktionen für den Umgang mit JSON-Inhalten.
- Andreas Scherbaum
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.