Konfigurationsdateien

Wo liegen die Dateien?

Der genaue Pfad hängt vom Betriebssystem und Paket-Layout ab:

Den korrekten Pfad findest du am schnellsten direkt im laufenden Server:

SHOW config_file;
SHOW hba_file;
SHOW ident_file;
SHOW data_directory;

Auf Ubuntu/Debian liegen die Config-Dateien unter /etc/postgresql/..., das Daten-Verzeichnis unter /var/lib/postgresql/... — anders als beim generischen Setup, wo alles im selben PGDATA liegt. Die SHOW-Befehle helfen, beim richtigen Mode nachzusehen.

postgresql.conf — der Hauptschalter

postgresql.conf enthält über 300 Parameter — von Speichergrößen über Logging bis zu Replikation. Wichtige Beispiele:

# Connections
listen_addresses = 'localhost'   # 'localhost', '*', '10.0.0.5', ...
port = 5432
max_connections = 100

# Memory
shared_buffers = 128MB
effective_cache_size = 4GB
work_mem = 4MB
maintenance_work_mem = 64MB

# WAL / Checkpoints
wal_level = replica
max_wal_size = 1GB
checkpoint_timeout = 5min

# Logging
log_destination = 'stderr'
logging_collector = on
log_directory = 'log'
log_min_duration_statement = 250ms
log_line_prefix = '%m [%p] %q%u@%d '

Es gibt drei Wege, die Werte zu setzen, mit aufsteigender Priorität:

1. postgresql.conf (samt eingebundenen Dateien)
2. ALTER SYSTEM SET … = …; schreibt in postgresql.auto.conf und überschreibt damit postgresql.conf
3. ALTER DATABASE … SET … / ALTER USER … SET … für Database/Role-spezifische Werte

Auf einem laufenden Server lohnt sich pg_settings für eine Komplettübersicht, was wie gesetzt ist:

SELECT name, setting, source, sourcefile, sourceline
FROM pg_settings
WHERE name IN ('shared_buffers','work_mem','log_min_duration_statement');

Reload vs. Restart

Nicht jede Änderung braucht einen Restart. Postgres unterscheidet drei Kontexte:

Praktisch: nach jeder Änderung kurz SHOW <parameter>; und prüfen, ob der neue Wert greift. Wenn nicht — Restart vergessen.

-- Welche Aenderungen warten gerade noch auf einen Restart?
SELECT name, setting, pending_restart
FROM pg_settings
WHERE pending_restart;

conf.d / Include-Mechanismen

postgresql.conf kennt drei Include-Direktiven, die Konfigurationen modular halten:

include 'extra.conf'
include_if_exists 'optional.conf'
include_dir 'conf.d'

Konvention auf den meisten Systemen: ein leeres conf.d/-Verzeichnis liegt neben postgresql.conf. Eigene Anpassungen kommen als nummerierte Dateien dort hinein:

ls /etc/postgresql/18/main/conf.d/
# 10-logging.conf
# 20-tuning.conf
# 50-replication.conf

Vorteil: Paket-Updates überschreiben deine Anpassungen nicht, und die Aufgaben sind sauber getrennt. Die letzte Datei in alphabetischer Reihenfolge gewinnt bei Konflikten.

pg_hba.conf — wer darf rein?

pg_hba.conf (Host-Based Authentication) ist eine zeilenbasierte Allow-Liste. Jede Zeile prüft fünf Felder, von oben nach unten, und die erste passende Zeile entscheidet:

# TYPE   DATABASE    USER       ADDRESS         METHOD
local    all         postgres                   peer
local    all         all                        scram-sha-256
host     all         all        127.0.0.1/32    scram-sha-256
host     all         all        ::1/128         scram-sha-256
host     replication replicator 10.0.0.0/24     scram-sha-256
hostssl  myapp       app        0.0.0.0/0       scram-sha-256

Was die Felder bedeuten:

Die wichtigsten Authentifizierungsmethoden:

• peer — Postgres prüft den Unix-User des Clients gegen den Postgres-Rollennamen. Nur für local. Standard für lokale Admin-Verbindungen.
• trust — kein Passwort, jeder darf rein. Gefährlich. Nur in geschlossenen Test-Setups.
• scram-sha-256 — modernes Passwort-Verfahren. Default seit PG 14.
• md5 — alter Passwort-Hash. Sollte nicht mehr genutzt werden, lebt nur noch wegen Legacy-Clients.
• cert — Client-Zertifikate (mTLS).
• ident — vergleichbar mit peer, aber für TCP. Braucht einen Ident-Server am Client. Selten.

Nach Änderung an pg_hba.conf reicht ein Reload (pg_ctl reload / SELECT pg_reload_conf()); ein Restart ist nicht nötig.

pg_ident.conf — Mapping zwischen OS-User und Postgres-Rolle

Die Methoden peer, ident und cert identifizieren den Client als OS-User oder Cert-CN — nicht direkt als Postgres-Rolle. pg_ident.conf schlägt die Brücke:

# MAPNAME      SYSTEM-USERNAME     PG-USERNAME
deploy_map     deploy              app
deploy_map     deploy              admin
admins         /^.*@example\.com$  postgres

In pg_hba.conf referenzierst du das Mapping per map=<mapname>:

local   all   all   peer   map=deploy_map

Damit darf sich der OS-User deploy als Postgres-Rolle app oder admin anmelden, ohne dass die Namen identisch sind. Der reguläre Ausdruck (Zeile 3) erlaubt sogar mehrere Cert-CNs. Praktisch für Service-Konten in Produktions-Setups.

Weiterführende Ressourcen

Externe Quellen

• Server Configuration – PostgreSQL Documentation
• The pg_hba.conf File – PostgreSQL Documentation
• User Name Maps (pg_ident.conf) – PostgreSQL Documentation
• ALTER SYSTEM – PostgreSQL Documentation
• pg_settings View – PostgreSQL Documentation

Verwandte Artikel

• Architektur-Überblick: Prozessmodell, WAL, MVCC
• PostgreSQL unter Ubuntu installieren
• psql – Einstieg in den PostgreSQL-Client
• Was ist PostgreSQL?