Valider l'ordre des règles de pg_hba.conf et recharger sans risque

Commande

-- File location
SHOW hba_file;

# Rules are read top to bottom and the FIRST matching rule wins;
# specific rules must come BEFORE general ones:
#   hostssl  appdb  web_app  10.10.0.0/16  scram-sha-256
#   host     all    all      10.10.0.0/16  reject
#   host     all    all      0.0.0.0/0     scram-sha-256

-- Validate BEFORE reloading: pg_hba_file_rules reads the file on disk
SELECT line_number, type, database, user_name, address, netmask, auth_method, error
FROM pg_hba_file_rules
ORDER BY line_number;

-- Apply if the error column is empty
SELECT pg_reload_conf();

Ce que fait la commande

Indique où se trouve pg_hba.conf, comment PostgreSQL l'interprète (ligne, type, base, utilisateur, adresse, méthode) et les éventuelles erreurs de syntaxe avant le reload ; puis recharge la configuration.

Quand l'utiliser

Lors de l'ajout d'un nouveau réseau client/d'une nouvelle application, de la migration de md5 vers scram-sha-256, ou de l'investigation d'erreurs 'no pg_hba.conf entry for host'.

Attention

pg_hba_file_rules montre le fichier tel qu'il est maintenant, pas les règles actives. Si une ligne a une valeur error non vide, un reload ne charge PAS du tout pg_hba.conf et les anciennes règles restent en vigueur (le journal indique 'pg_hba.conf was not reloaded'). Les changements n'affectent que les nouvelles connexions. Une règle large placée tôt (par ex. host all all 0.0.0.0/0 trust) neutralise toutes les restrictions qui la suivent. Avec SSL désactivé, les lignes hostssl ne peuvent pas correspondre et affichent un message dans la colonne error. Par défaut, seuls les superutilisateurs peuvent lire la vue. Assurez-vous que les outils qui modifient le fichier en root ne changent pas son propriétaire ; si l'utilisateur postgres ne peut pas le lire, le reload échoue.