PostgreSQL

Documentation technique

Packaging

PostgreSQL est déjà packagé par nixpkgs. Cependant, à cause d’une dépendance à PAM non compilée dans la version de base, tout doit être recompilé (Note: cette dépendance à PAM implique beaucoup de recompilation en cascade notamment à cause de Qt)

Configuration

Pour éviter les redémarrages imprévus de PostgreSQL en période de maintenance, les services qui nécessitent PostgreSQL ne déclarent pas la dépendance systemd comme Wants ou Require, mais comme Requisite. Cela permet d’avoir une dépendance forte (le service dépendant ne peut pas démarrer sur PostgreSQL n’est pas démarré) sans pour autant qu’elle provoque un (re)démarrage de PostgreSQL.

Divers aides ont été ajoutées pour permettre une maintenance sans heurts (fichier /var/tmp/no-postgresql pour empêcher les services dépendants de démarrer même si PostgreSQL tourne, target pour arrêter ou redémarrer tous les services d’un coup, etc.)

Mises à jour

Les mises à jour de PostgreSQL ne doivent pas sauter de version. Cependant, une compatibilité ascendante est assurée partiellement (voir les release notes plus bas), ce qui permet de mettre à jour sans grand danger pour les services qui en dépendent. Le processus de mise à jour, partiellement documenté sur le manuel de NixOS, se déroule de la façon suivante :

  • S’assurer que le serveur est déployé correctement

  • Éditer le fichier flakes/mypackages/overlays/databases/postgresql/default.nix pour changer les valeurs de postgresql_system, postgresql_pam, postgresql_system_next et postgresql_system_pam.

  • Prévoir également la configuration pour le dataset ZFS (le script d’upgrade plus loin se chargera de la création initiale).

  • Compiler la nouvelle version sans la déployer (elle prend du temps, possiblement quelques heures !)

  • Une fois la version compilée, sur le serveur un script upgrade-pg-cluster permet d’arrêter PostgreSQL et mettre à jour le cluster vers la nouvelle version.

  • Enfin, déployer le nouveau système. Les outils devraient être redémarrés.

  • Jusqu’à la version PostgreSQL 14, un script ./analyze_new_cluster.sh peut être lancé pour optimiser la base

  • Les serveurs de réplications suivent le même processus, il ne doit pas y avoir plus d’une version d’écart entre les deux. Le serveur primaire doit toujours être en avance sur le serveur de réplication.

Changement de collation

Lors de mises à jour, il se peut qu’un changement dans la libc (?) rende invalide les index de la base de données. Cela se traduit par un message de postgres de la forme:

The database was created using collation version 2.37, but the operating system provides version 2.40.
Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Dans ce cas, avant de lancer la commande donnée en message, il faut reconstruire les index (attention, ça bloque l’accès pendant la reconstruction):

$ sudo -u postgres reindexdb --all
# Ou la commande psql équivalente pour le faire une bdd à la fois
postgres=# REINDEX DATABASE (CONCURRENTLY);

Ensuite on peut lancer le refresh sur chaque base de données:

ALTER DATABASE postgres REFRESH COLLATION VERSION;

Suivi des versions

Suivi des CVE

Accès / Suppression des données

PostgreSQL stocke la majorité des données utilisateur. Cependant, il ne les stocke pas en propre. Chaque application utilisant a ses propres informations pour récupérer les données utilisateur.