Administration on Carnet de découvertes

Poissons et coquillages

Florent Jardin — Mon, 14 Oct 2024 10:30:00 +0200

En tant que pur produit académique des années 2010, mon langage de script de prédilection a toujours été le Bash (Bourne Again Shell). Non sans ignorer qu’il ait pu en exister d’autres, je ne me suis jamais vraiment tourné vers d’autres shells pour automatiser les tâches du quotidien dans mon métier de DBA.

Et pour cause, j’ai administré des centaines de serveurs de distributions très variées et il n’était pas bien vu d’installer des dépendances systèmes lourdes pour enrichir des scripts Python ou Perl. Nous apprenions donc à écrire des scripts portables et universels, compatibles partout où nous déposions nos valises.

Me suis-je enfermé dans un dogme conservateur, en m’interdisant de facto à me tourner vers des shells modernes et bien plus aisés à appréhender ?

Beurk, le Bash

Ne faisons pas de détour, le Bash c’est moche. Puissant, pratique, universel, mais moche.

Vous pourriez penser que c’est un avis parfaitement subjectif, et qu’il ne faut pas juger un livre à sa couverture… mais avouez-le, une partie de vous pense sensiblement la même chose que moi. Combien d’heures ai-je pu perdre durant ma courbe d’apprentissage du langage, à cause d’un grand nombre de subtilités et de pièges de syntaxes ?

Entre les assignations sans espace autour du signe =, les accolades {} pour les variables contenant un signe _, les backticks ` ` pour les commandes subshells, ou encore les doubles crochets [[ ... ]] pour les comparaisons non-POSIX, il y a de quoi s’arracher les cheveux.

Certain·e·s y verront une forme d’esthétisme ou de tradition d’une culture informatique, mais personnellement je trouve que c’est un langage qui vieillit mal, très mal. Vous ne vous offusqueriez pas non plus si je devais vous témoigner mon désamour le Perl, n’est-ce pas ?

# une comparaison de deux variables
[[ "$a" == "$b" ]]

# une addition et une affectation
z=$(( $x + $y ))

# une boucle for
for i in $(seq 1 10); do
 echo $i
done

# un switch case
case $1 in
 1) echo "un";;
 2) echo "deux";;
 *) echo "autre";;
esac

# une chaîne en minuscule
a=${a,,}

# une gestion des erreurs de commandes chaînées
some_command | another_command
if [[ ${PIPESTATUS[0]} -ne 0 || ${PIPESTATUS[1]} -ne 0 ]]; then
 echo "Une des commandes a échoué"
fi

Le Bash est apparu l’année de ma naissance, en 1989. Il a été conçu en opposition au Bourne Shell (sh) pour apporter des fonctionnalités de programmation plus avancées. Il est devenu le shell par défaut de la plupart des distributions Linux, et est devenu un standard pour tous les scripts à travers le monde entier.

Fort de ses années de succès, et de son emprise sur le monde Unix, le Bash s’impose parfois comme la première porte vers la programmation pour des administrateurices système ou les étudiant·e·s en informatique. Et il faut accepter que la qualité de ses premiers scripts n’est pas toujours au rendez-vous. Souvenez-vous des longues heures passées sur StackOverflow à trouver la syntaxe la plus lisible ou la plus efficace, car les réponses se révélaient aussi variées que touffues !

Et c’est l’un des plus gros problèmes que je trouve au Bash : ce langage de programmation est exigeant, excentrique, voire idiosyncratique, et qui ne pardonne pas les erreurs. Un des paradoxes que j’associe au Bash est qu’il peut ne pas être considéré comme un véritable langage de programmation, réduisant ainsi la volonté et l’effort de l’apprendre en profondeur par une large communauté de professionnel·le·s.

Et si vos scripts Bash sont nuls, utilisez un autre langage.

L’ami Fish, Friendly Interactive Shell

Je suis tombé sur Fish par hasard, alors que je questionnais mon usage quotidien sur ZSH. Sur mon poste personnel, j’ai étendu mon expérience passée sur le Bash avec une configuration ZSH enrichie de Oh My Zsh. C’était un peu le jour et la nuit dans l’interaction avec mes terminaux : la navigation, les suggestions, les thèmes, les plugins, tout est plus fluide et plus agréable. Sa compatibilité avec Bash m’avait alors évité de tout réapprendre.

Fish répond au besoin de modernité et de simplicité que je cherche sans vraiment le savoir. Contrairement à ZSH, un grand nombre de fonctionnalités sont disponibles sans aucune configuration préalable ou plugin à activer.

Assistance à la commande

Recopie la commande incomplète et en erreur sans besoin de naviguer dans l’historique
Accès à l’historique partiel avec les touches directionnelles dès la première frappe au clavier
Proposition de chemins avec la complétion de la touche Tab, suivie des touches directionnelles

Auto-suggestions des chemins et des options d’une grande majorité des outils

Mémoire des précédents répertoires parcourus
Support très complet des commandes Git, notamment le git rebase -i ❤️

Coloration plus poussée des commandes

une couleur différente par mot selon la syntaxe employée (variables, chemin, options)
un rouge prononcé pour les commandes inconnues

Un langage qui vous veut du bien

Pour revenir au sujet principal de cet article, Fish révolutionne notre rapport avec la rédaction de scripts. Fini les pièges et la syntaxe qui nous ont tenu en otage durant des années. Les choses deviennent bien plus simples et lisibles.

# une comparaison de deux variables
test "$a" = "$b"

# une addition et une affectation
set z (math $x + $y)

# une boucle for
for i in (seq 1 10)
 echo $i
end

# un switch case
case $argv[1]
 1; echo "un"
 2; echo "deux"
 *; echo "autre"
end

# une chaîne en minuscule
set a (string lower $a)

# une gestion des erreurs de commandes chaînées
some_command | another_command
if contains 1 $pipestatus
 echo "Une des commandes a échoué"
end

L’investissement initial pour perdre ses habitudes acquises avec Bash est modéré, notamment le remplacement de export ou de l’assignation = par la méthode set -x ou set -u respectivement. Mais l’enrichissement du langage par quelques nouveaux mots-clés permet d’alléger le script avec des syntaxes claires et lisibles (contains, math ou string présents dans l’exemple ci-dessus).

L’ajout de plugins communautaire n’est pas en reste, si comme moi, vous en consommiez avec Oh-My-ZSH. L’outil Fisher s’installe dans votre ~/.config/fish et donne accès à un gestionnaire complet et sobre. Pour ma part, j’ai pu rapidement combler mon besoin de charger les variables d’environnement fournies par l’agent SSH (ssh-agent) lors du démarrage de ma session.

$ fisher install danhper/fish-ssh-agent
fisher install version 4.4.5
Fetching https://api.github.com/repos/danhper/fish-ssh-agent/tarball/HEAD
Installing danhper/fish-ssh-agent
 /home/florent/.config/fish/functions/__ssh_agent_is_started.fish
 /home/florent/.config/fish/functions/__ssh_agent_start.fish
 /home/florent/.config/fish/conf.d/fish-ssh-agent.fish
Updated 1 plugin/s

Pas de mystère, ni d’arcanes magiques, votre environnement est enrichi de nouvelles fonctions et de scripts de démarrage, développés en Fish.

Osons la modernité

La documentation du projet est très bien fournie. En plus de la page Tutorial, vous trouverez une page dédiée aux utilisateurs de Bash pour vous aider à réussir votre transition. Pour ma part, j’y retrouve des syntaxes bien plus proches du Python, et c’est un vrai plaisir.

Le projet est vivant, avec un rythme de versions régulier. Je me suis surpris moi-même à ne pas en avoir entendu parler par d’autres collègues ou auprès des auteurices de blogs que je suis. Au cours des dernières années, la communauté francophone a essaimé quelques bons articles qui complètent le mien.

Changer de shell, de Bash à Fish (2016)
Fish, une ligne de commande intelligente et simple d’utilisation (2017)
Comment passer de Bash à Fish Shell sous Linux (2021)
Migration de shell de zsh à fish (2024)

Ces temps-ci, je fais évoluer mon expérience d’utilisateur de Linux avec une transition vers Wayland et SwayWM (j’y reviendrais dans un autre article). Je ne le cache pas, la tentation de remplacer mes scripts Bash qui gèrent mes thèmes ou les composants swaybar, est forte, très forte.

De quoi occuper mes prochaines longues soirées d’hiver.

Les corruptions silencieuses

Florent Jardin — Tue, 28 Sep 2021 00:00:00 +0000

Parmi les drames universellement reconnus, les corruptions de données sont des événements mécaniques ou logiques qui surviennent à des moments imprévisibles. Tantôt il s’agira de l’âge avancé des secteurs disques, tantôt il s’agira d’une extinction inopinée d’un composant électrique ou d’une perte de paquet dans les protocoles de cache.

Bien que peu de personnes peuvent se vanter d’en avoir observé au cours de leur carrière, les corruptions sont particulièrement dévastatrices lorsqu’elles se sont propagées sur les supports de sauvegardes et détectées bien des jours, voire des semaines après l’incident. Les moteurs de bases de données sont très résilients face à ces destructions de données, en proposant des mécanismes de journalisation adaptés. Malgré cela, des précautions sont de mises.

La surcorruption

La détection d’une corruption n’est jamais très claire, ni très précise. Dans la majorité des situations, il s’agit d’un utilisateur qui reporte une erreur lors de la lecture d’une ligne dans la base de données et ne parvient pas à finaliser son traitement. Avec PostgreSQL, la première source exploitable reste le journal de l’instance, dans lequel l’anomalie sera flagrante avec des messages d’erreur de type could not read block xxx in file ou invalid page (header) in block xxx of relation.

Les corruptions peuvent aussi bien toucher les index que les tables. Les premières peuvent provoquer des ralentissements pour certaines requêtes, voire remonter des données erronées, alors que les secondes sont bien plus problématiques avec la destruction simple d’une partie des données utilisateurs.

Après un constat désarmant de corruption, la sueur perle probablement sur le front des équipes techniques, si tant est que l’information leur ait été remontée dans un court laps de temps. La corruption est-elle réversible avec une copie quelconque de la table dans une instance secondaire, ou dans une sauvegarde ? La corruption est-elle présente depuis longtemps ? Le système présente-t-il des messages alarmants sur l’état des écritures sur le volume ?

Le meilleur des conseils que trop peu se permettent, serait de se prévenir d’une surcorruption en arrêtant les écritures le plus tôt possible. Le temps d’identifier l’origine de la corruption, en mobilisant plusieurs équipes pour éplucher les logs des hyperviseurs, des baies de stockages ou du fournisseur Cloud, il se peut (statistiquement) qu’une autre corruption porte atteinte à la vie des données saines du système.

Il est aussi indispensable de procéder à une copie bas niveau du répertoire de données de l’instance et de travailler exclusivement sur un exemplaire de ladite copie, a minima sur des disques différents, au mieux, sur un serveur secondaire.

Récupérer ce qui peut l’être

Pour illustrer la complexité que peut devenir la récupération de données saines sur une base corrompue, j’ai malmené une instance jetable en version 13 dont les données de la table pgbench_accounts ont été partiellement détruites avec l’outil fallocate.

Élargir la recherche des corruptions est possible en forçant la lecture intégrale des données contenues dans les tables. Avec PostgreSQL, le plus simple consiste à exporter les bases avec pg_dump, de surveiller la sortie d’erreurs… et d’espérer qu’aucune donnée ne soit perdue.

$ pg_dump demo 1> /dev/null

Dumping the contents of table "pgbench_accounts" failed: PQgetResult() failed.
Error message from server:
 ERROR: invalid page in block 20 of relation base/16997/17010
The command was:
 COPY public.pgbench_accounts (aid, bid, abalance, filler) TO stdout;

L’incertitude s’installe à l’issue de la commande. L’une des pages de la table pgbench_accounts présente une malformation, rendant impossible la lecture de 8 ko de données. La récupération des données encore exploitable peut être possible, notamment à travers l’index de clé primaire et une recherche par dichotomie sur les valeurs disponibles dans le fichier corrompu.

SET enable_seqscan = off;

COPY (SELECT aid, bid, abalance, filler
 FROM pgbench_accounts WHERE aid < 1221)
 TO stdout;

COPY (SELECT aid, bid, abalance, filler
 FROM pgbench_accounts WHERE aid > 1281)
 TO stdout;

Si tant est que cette table soit concernée par une contrainte de clé étrangère, l’ensemble du modèle devient alors partiellement incohérent et les données orphelines sont destinées à être détruites explicitement pour valider la contrainte.

ALTER TABLE pgbench_history
 ADD FOREIGN KEY (aid) REFERENCES pgbench_accounts(aid);

-- ERROR: insert or update on table "pgbench_history" violates
-- foreign key constraint "pgbench_history_aid_fkey"
-- DETAIL: Key (aid)=(1276) is not present in table "pgbench_accounts".

DELETE FROM pgbench_history h
 WHERE NOT EXISTS
 (SELECT aid FROM pgbench_accounts WHERE aid = h.aid);

ALTER TABLE pgbench_history
 ADD FOREIGN KEY (aid) REFERENCES pgbench_accounts(aid);

-- ALTER TABLE

Se protéger des corruptions

Comme précisé en introduction, la plupart des moteurs de bases de données sont résilients et articulent leurs écritures autours de la journalisation. Chaque modification est assurée d’être écrite sur un stockage non volatile à la réception du COMMIT de la transaction. Cela implique une synchronisation des blocs en mémoire vers le stockage du système comme je l’avais illustré dans un précédent article.

Des précautions sont bien sûr nécessaires, et Craig Ringer avait compilé dans un article en 2012, des recommandations toujours pertinentes pour réduire le risque de corruptions.

Mettre à jour votre instance à la dernière version mineure disponible ;
Ne pas désactiver fsync et privilégier les paramètres synchronous_commit et commit_delay ;
Ne pas tuer les processus PostgreSQL et utiliser les fonctions système pg_cancel_backend et pg_terminate_backend pour arrêter une requête longue ;
Ne pas supprimer le contenu du répertoire de données, à l’exception des traces d’activité au format texte ;
Ne pas modifier le catalogue système (pg_catalog.*) ;
Conserver les sauvegardes sur de longues périodes à raison d’une par semaine, une par mois, voire une par année pour reconstruire les données corrompues (avec un peu de chance tout de même) ;
Mettre en place de la réplication et des sauvegardes physiques, avec un politique de rétention des journaux de transactions sur de longues périodes ;
Éviter les disques en RAID5 et privilégier le RAID10 pour les disques mécaniques ;
Ne pas utiliser les systèmes de fichiers exotiques comme (ZFS), BTRFS ou FAT32 ;
Ne pas stocker les fichiers de l’instance sur une clé USB ou un montage réseau.

Depuis quelques années, le projet ZFS s’est ouvert à la communauté avec OpenZFS en 2013. En plus des fonctionnalités de Copy on Write, de Snapshot ou de Mirroring, ce système de fichiers couvre également l’aspect des sommes de contrôle, le rendant bien plus résilient qu’à l’époque où Craig Ringer écrivait ses recommandations.

Malgré toutes ces protections, une autre forme de corruption peut encore survenir. Une donnée erronée peut être retournée au client sans message d’erreur. On parle alors de corruption silencieuse.

Prenons l’exemple d’une donnée dans la table pgbench_branches :

UPDATE pgbench_branches SET filler = 'florent';
SELECT pg_relation_filepath('pgbench_branches');

-- pg_relation_filepath
-- ----------------------
-- base/17100/17179

À l’aide d’un éditeur hexadécimal, je suis libre d’émuler une corruption silencieuse en ciblant précisément une donnée de type text. Ici, je remplace quelques octets pour transformer florent en fl4r%nt.

hexedit base/17100/17179

00001F64 00 00 00 00 00 00 00 00 00 00 00 00 ............
00001F70 02 00 03 80 02 29 18 00 01 00 00 00 .....)......
00001F7C 00 00 00 00 B3 66 6C 34 72 25 6E 74 .....fl4r%nt
00001F88 20 20 20 20 20 20 20 20 20 20 20 20
00001F94 20 20 20 20 20 20 20 20 20 20 20 20
00001FA0 20 20 20 20 20 20 20 20 20 20 20 20
00001FAC 20 20 20 20 20 20 20 20 20 20 20 20

Pour cette démonstration, ce changement a été fait à froid, c’est-à-dire instance arrêtée et fichiers fermés. Une copie du bloc pouvant encore être dans le cache mémoire de PostgreSQL, le prochain CHECKPOINT ou synchronisation préventive aurait réécrit le bloc sain à l’intérieur du fichier.

Au redémarrage de l’instance, le contenu de la table est erroné, mais PostgreSQL n’aura détecté aucune anomalie de corruption dans le bloc de fichier.

SELECT * FROM pgbench_branches;

-- -[ RECORD 1 ]---------
-- bid | 1
-- bbalance | 0
-- filler | fl4r%nt

Depuis la version 9.3 de PostgreSQL, publiée en septembre 2013, il est possible d’activer les sommes de contrôles pour les données d’une instance afin de contrôler l’état d’un bloc entre son écriture et ses futures lectures, évitant alors tout risque de corruption silencieuse.

Cette opération nécessite pour les versions 11 et inférieures, que l’instance soit créée avec ce mode particulier. Depuis la version 12, l’utilitaire pg_checksums permet d’activer et de désactiver le mécanisme de sommes de contrôle sur le répertoire de données d’une instance arrêtée, sans besoin de migrer vers une nouvelle instance comme il était nécessaire dans les versions précédentes.

$ pg_checksums --pgdata=$PGENV_ROOT/pgsql/data --enable

Checksum operation completed
Files scanned: 3097
Blocks scanned: 109156
pg_checksums: syncing data directory
pg_checksums: updating control file
Checksums enabled in cluster

Dans ce nouveau contexte, je réalise à une nouvelle fois un UPDATE sur la table…

UPDATE pgbench_branches SET filler = 'florent';
CHECKPOINT;

… et je corromps la donnée de la table pgbench_branches. Au redémarrage, PostgreSQL remonte correctement une anomalie de sommes de contrôle sur le bloc qui contient la donnée corrompue :

SELECT * FROM pgbench_branches;

-- WARNING: page verification failed, calculated checksum 35393 but expected 2501
-- ERROR: invalid page in block 0 of relation base/17100/17179

Conclusion

Les corruptions sont des événements rarissimes et imprévisibles. Il est communément admis que les dégâts sont irréversibles dans un grand nombre de situations, en l’absence de contre-mesures suffisantes.

À moins d’avoir une confiance aveugle dans l’infrastructure matérielle qui héberge vos instances, l’activation des sommes de contrôle représente à ce jour le mécanisme le plus complet pour identifier rapidement toutes les formes de corruptions sur les données de vos bases.

Mauvaise nouvelle : ce mécanisme n’est pas actif par défaut.

À vous d’intégrer l’option --data-checksums de l’utilitaire initdb lors du provisionnement de toutes vos nouvelles instances. Enfin, privilégiez une version 12 ou supérieure, car vous ne regretterez pas le gain de temps que vous apportera pg_checksums !

Compiler et patcher avec pgenv

Florent Jardin — Mon, 21 Dec 2020 00:00:00 +0000

Parmi les quelques outils de mon quotidien, il y en a un très sobre et bigrement efficace répondant au nom de pgenv, un gestionnaire des versions PostgreSQL. Ce projet est publié sous licence MIT par David E. Wheeler, auteur de l’extension pgTAP dont j’avais déjà vanté les mérites dans un autre article.

Cet outil concerne principalement les contributeur⋅rices au projet PostgreSQL et les quelques DBA féru⋅es d’expérimentations, car pgenv permet de compiler et d’exécuter toutes les versions majeures et mineures du système de base de données open-source le plus avancé du monde.

À l’épreuve de la compilation

PostgreSQL est particulièrement simple à compiler. Avec un poste de travail sous Unix, GNU/Linux ou BSD et quelques dépendances, à savoir gcc, make, patch et git, il est facile d’exécuter une instance dans la version cible de son choix.

$ git clone git://git.postgresql.org/git/postgresql.git
$ cd postgresql
$ git checkout REL_13_1

$ export PREFIX=/tmp/postgres/devel
$ ./configure --prefix=$PREFIX
$ make && make install

$ cd contrib
$ make && make install

Dès lors que les librairies et les binaires sont disponibles, il est très aisé de contruire sa première instance et de s’y connecter !

$ export PATH=$PREFIX/bin:$PATH
$ export LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
$ export PGDATA=/tmp/postgres/data

$ initdb --username $(whoami) --auth=peer --data-checksums
$ pg_ctl start --log=$PGDATA/server.log

$ createdb $(whoami)
$ psql -tc "select version()"
 PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.2.0, 64-bit

$ pg_ctl stop

Le faire à la main m’a amusé quelques minutes et écrire un script pour automatiser le déploiement des versions mineures à la demande m’a vite traversé l’esprit. Ne réinventons pas la roue et voyons ce que propose pgenv !

Un script pour les compiler tous

La page d’accueil du projet reprend l’installation rapide du script dans votre sous-répertoire ~/.pgenv. Téléchargeons et compilons la version qui nous interesse.

$ pgenv available
 Available PostgreSQL Versions
================================================
 ...
 PostgreSQL 10
------------------------------------------------
 10.0 10.1 10.2 10.3 10.4 10.5
 10.6 10.7 10.8 10.9 10.10 10.11
 10.12 10.13 10.14 10.15

 PostgreSQL 11
------------------------------------------------
 11.0 11.1 11.2 11.3 11.4 11.5
 11.6 11.7 11.8 11.9 11.10

 PostgreSQL 12
------------------------------------------------
 12.0 12.1 12.2 12.3 12.4 12.5

 PostgreSQL 13
------------------------------------------------
 13beta1 13beta2 13beta3 13rc1 13.0 13.1

Comme pour mon précédent exemple, je réinstalle une version 13.1 avec pgenv à l’aide de l’option build. Le script déploie également les librairies de contrib et la documentation.

$ export PGENV_ROOT=/var/lib/pgenv
$ export PATH=$PGENV_ROOT/pgsql/bin:$PATH
$ export LD_LIBRARY_PATH=$PGENV_ROOT/pgsql/lib:$LD_LIBRARY_PATH

$ pgenv build 13.1
PostgreSQL, contrib, and documentation installation complete.
pgenv configuration written to file /var/lib/pgenv/.pgenv.13.1.conf
PostgreSQL 13.1 built

On retrouve dans l’arborescence $PGENV_ROOT, la présence de l’archive .tar.bz2 du projet, requise pour l’étape de compilation. Le $PREFIX quant à lui, est automatiquement positionné sur le répertoire $PGENV_ROOT/pgsql-13.1.

/var/lib/pgenv
├── .pgenv.13.1.conf
├── pgsql-13.1
│   ├── bin
│   ├── include
│   ├── lib
│   └── share
└── src
 ├── postgresql-13.1
 └── postgresql-13.1.tar.bz2

Pour être fidèle à ma première partie, je vais configurer correctement les paramètres de la commande initdb dans le fichier de configuration dédié à la version 13.1.

$ pgenv config edit 13.1
# Path to the cluster log file (mandatory)
PGENV_LOG="$PGENV_ROOT/pgsql/data/server.log"

# Initdb flags
PGENV_INITDB_OPTS="--username $(whoami) --auth=peer --data-checksums"

Ainsi, lors de la première utilisation de cette version 13.1, pgenv va lancer la commande initdb pour alimenter le répertoire de données avec mon compte comme propriétaire et démarrer le processus postgres.

$ pgenv use 13.1
Using PGENV_ROOT /var/lib/pgenv
Data page checksums are enabled.
Success. You can now start the database server using:
 /var/lib/pgenv/pgsql/bin/pg_ctl -D /var/lib/pgenv/pgsql/data -l logfile start

PostgreSQL 13.1 started
Logging to /var/lib/pgenv/pgsql/data/server.log

$ createdb $(whoami)
$ psql -tc "select version()"
 PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 10.2.0, 64-bit

Et avec ceci ?

Comme indiqué en introduction, l’intérêt d’un tel gestionnaire réside dans sa capacité d’installer plusieurs versions différentes dans la même arborescence et de basculer de l’une à l’autre.

Imaginons que nous souhaitons disposer d’une version 10 de PostgreSQL avec le même genre de configuration que la version 13 précédente. pgenv supporte un fichier d’environnement global, nommé .pgenv.conf, que je reconstruis à partir de mon précédent fichier d’instance 13.1.

$ cp $PGENV_ROOT/.pgenv.13.1.conf $PGENV_ROOT/.pgenv.conf
$ pgenv build 10.15
$ pgenv use latest 10

$ createdb $(whoami)
$ psql -c "show data_checksums"

 data_checksums
 ----------------
 on
 (1 row)

Nous nous retrouvons bien avec un instance dont les sommes de contrôle ont été activées, grâce à l’option PGENV_INITDB_OPTS citée plus haut.

Je m’étais questionné sur la capacité de pgenv de lancer simultanément deux environnements pour mettre en place de la réplication logique, par exemple. Conclusion, il s’agit d’une des limites de l’outil, puisque ce n’est pas son but premier. Et pour cause, à chaque fois que l’on appelle la commande pgenv use, le script arrête l’instance courante avant de basculer sur la deuxième.

$ pgenv use latest 10
Using PGENV_ROOT /var/lib/pgenv
PostgreSQL 13.1 stopped
PostgreSQL 10.15 started
Logging to /var/lib/pgenv/pgsql/data/server.log

En complément, pgenv met en place un lien symbolique dans la racine $PGENV_ROOT à chaque changement de version courante. Ce lien a été ajouté au préalable dans la variable $PATH pour garantir la bonne compatibilité des binaires avec les données.

/var/lib/pgenv
├── .pgenv.13.1.conf
├── .pgenv.conf
├── pgsql -> pgsql-10.15
├── pgsql-10.15
├── pgsql-13.1
└── src

Ce lien symbolique nous oblige à manipuler toutes les autres instances avec des chemins absolus, une surcharge de leurs paramètres port ou listen_addresses et de faire appel à la bonne version de la commande pg_ctl. Il est donc possible de faire de la réplication, mais oubliez pgenv pour la gestion des processus d’instances.

Dans la cour des grands

Nous sommes en décembre 2020 à l’heure de la rédaction de cet article, et la communauté PostgreSQL travaille activement sur le développement de la prochaine version 14 du logiciel. Chaque année, les contributeur⋅rices du monde entier se retrouvent en ligne autour du Commitfest pour étudier les nouvelles propositions de fonctionnalités ou de correction de bogues.

En août dernier, Tatsuro Yamada proposait d’enrichir les méta-commandes de l’invite psql afin de lister les statistiques étendues rattachées aux tables de la base courante. Cette fonctionnalité est donc étudiée à travers les échanges électroniques et suivie sur une page dédiée du Commitfest.

Le contributeur produit alors un fichier .patch qu’il obtient avec la commande git diff et dont le résultat est compatible avec la commande patch. Ainsi, n’importe quel relecteur peut l’intégrer dans son projet et dérouler ses tests sur la nouvelle instance compilée.

C’est là qu’intervient une chouette fonctionnalité de l’outil pgenv. Ce dernier propose d’appliquer une série de patchs dans une phase préliminaire dès lors qu’on lui présente un fichier d’index pour la version associée, qui contiendra le chemin absolu des fichiers à parcourir.

/var/lib/pgenv
└── patch
    ├── 13
 │   └── 0001-Add-dX-command-on-psql-rebased-on-7e5e1bba03.patch
    └── index
 └── patch.13

Comme on le voit dans mon arborescence, j’ai téléchargé la dernière version communiquée par le développeur et je l’ai déclarée dans le fichier index.13. Lors de la recompilation de la version concernée, on constate que le patch est bien pris en compte.

$ export PGENV_DEBUG=1
$ pgenv clear
$ pgenv rebuild 13.1
Using PGENV_ROOT /var/lib/pgenv
[DEBUG] Patch index file [/var/lib/pgenv/patch/index/patch.13]
[DEBUG] Applying patch [0001-Add-dX-command-on-psql-rebased-on-7e5e1bba03.patch]
 into source tree /var/lib/pgenv/src/postgresql-13.1
Applied patch 0001-Add-dX-command-on-psql-rebased-on-7e5e1bba03.patch
PostgreSQL 13.1 built

Et la fonctionnalité devient disponible sur l’instance !

florent=# \dX
 List of extended statistics
 Schema | Name | Definition | Ndistinct | Dependencies | MCV
--------+-------+--------------+-----------+--------------+---------
 public | stts1 | a, b FROM t1 | | defined |
 public | stts2 | a, b FROM t1 | defined | defined |
 public | stts3 | a, b FROM t1 | defined | defined | defined
 public | stts4 | b, c FROM t2 | defined | defined | defined
(4 rows)

Le retrait des patchs n’est pas supporté par pgenv mais l’opération reste triviale avec la commande patch et son option --reverse. Cela nous permet de conserver les sources sans devoir les télécharger à nouveau !

$ cd $PGENV_ROOT/src/postgresql-13.1
$ index=$PGENV_ROOT/patch/index/patch.13
$ for f in $(cat $index); do patch --reverse -p1 < $f; done

patching file doc/src/sgml/ref/psql-ref.sgml
Hunk #1 succeeded at 1903 (offset -15 lines).
patching file src/bin/psql/command.c
Hunk #1 succeeded at 929 (offset 1 line).
patching file src/bin/psql/describe.c
Hunk #1 succeeded at 4377 (offset -24 lines).
patching file src/bin/psql/describe.h
patching file src/bin/psql/help.c
patching file src/bin/psql/tab-complete.c
Hunk #1 succeeded at 1479 (offset -21 lines).
Hunk #2 succeeded at 3771 (offset -127 lines).

Conclusion

Pour tout vous dire, je ne sais plus me séparer de pgenv sauf en de rares exceptions où mes tests nécessitent une distribution GNU/Linux spécifique, comme CentOS ou Debian. Une machine virtuelle fournie par Vagrant est tout aussi fiable, notamment lorsqu’il s’agit de déboguer un paquet d’installation ou une dépendance particulière.

$ sudo vagrant box list
centos/7 (libvirt, 2004.01)
debian/buster64 (libvirt, 10.4.0)
debian/stretch64 (libvirt, 9.12.0)

De Jekyll à Hugo

Florent Jardin — Wed, 09 Dec 2020 00:00:00 +0000

Dans l’univers des générateurs de sites statiques, la bataille fait rage entre plusieurs frameworks depuis quelques années. Vous avez peut-être entendu parler de Jekyll, Next.js, Gastby ou Hugo ? Je ne cite que les plus sollicités par la communauté sur GitHub, mais il en existe des centaines.

Pourquoi cet engouement ? Cet article n’en parlera pas.

Pour de louables raisons, je m’étais engagé l’année dernière à auto-héberger mon nouvel espace d’expression personnel. J’y ai découvert avec intérêt et amusement de nombreuses technologies que j’ai pliées, réinstallées, transformées pour les adapter à mon besoin. Sans trop rentrer dans les détails, j’ai fini par avoir :

un serveur VPS chez OVH pour un coût de 3,99€ par mois
une routine mensuelle de renouvellement de certificat avec certbot
une instance Theia dans un conteneur Docker
une image Jekyll 4.1.0 que j’invoquais dans Docker
deux dépôts GitHub privés pour les articles (posts) et les brouillons (drafts)
le thème Poole, léger et modulable… que j’ai modulé

Alors que la question de conserver ou non le serveur VPS se pose pour la nouvelle année qui démarre bientôt (il devient agé, limité, pour ne pas dire sénil), j’ai remis récemment en cause mon attachement pour le framework Jekyll, si élégant à l’époque.

Le machin repose sur des dépendances Ruby. Aussi nombreuses (ou presque) qu’un nouveau projet en Node.js. J’ai mangé du Gemfile par le passé, aussi je n’ai eu aucune réelle difficulté à installer les quelques modules nécessaires à la concrétisation de mon projet. En voici le contenu :

source "https://rubygems.org"

gem "jekyll", "~> 4.1.0"
gem "classifier-reborn"

# If you have any plugins, put them here!
group :jekyll_plugins do
 gem "jekyll-paginate-v2"
 gem 'jekyll-target-blank', "~> 2.0"
 gem 'jekyll-time-to-read'
end

Et c’est tout.

Je n’avais besoin que de la pagination et de l’estimation du temps de lecture par article. Mine de rien, ça me semblait un peu grossier d’exiger que ces simples modules ne soient pas intégrés nativement. J’ai donc engagé mes recherches et le portage du présent site sur l’une des autres solutions, à savoir Hugo.

Migre moi ça, p’ti con

Et les développeurs de Hugo n’y sont pas allé de main morte pour asseoir leur logiciel dans ce paysage turbulent : ils intègrent un assistant de migration spécialement pour un projet Jekyll en récupérant ses fichiers .md et ses ressources statiques. En soit, la chose n’est pas complexe et le résultat est au rendez-vous. Mais…

$ hugo import jekyll blog blog_hugo
Importing...
Congratulations! 128 post(s) imported!
Now, start Hugo by yourself:
$ cd blog_hugo
$ git clone https://github.com/spf13/herring-cove.git themes/herring-cove
$ hugo server --theme=herring-cove

Bien sûr, l’assistant propose un thème pour embellir le projet en lieu et place d’une transposition du language Liquid sur lequel repose les fichiers modèles de Jekyll. C’est plus simple mais… ce n’est pas réellement ce que je souhaitais.

Autant le rendu des articles est impeccable avec ce thème, autant la navigation est assez pauvre à mon goût. Bien évidemment, c’est bien suffisant pour n’importe qui. Mais voilà. Mon thème principal me manquait et malheureusement pour moi, il n’existait pas pour Hugo.

De longues soirées d’hiver

J’aime les choses simples. Et j’aime encore plus les comprendre en profondeur. C’est pour cette raison que je me suis lancé plusieurs heures dans la lecture assidue de la documentation très riche sur gohugo.io. Les concepts sont assez différents et le passage n’a pas été si évident que cela. Je vous propose un florilège des astuces qu’il m’a fallu découvrir pour proposer le portage intégral de mon site.

Les permaliens

Jekyll et Hugo proposent une gestion fine des URL à l’aide du paramètre permalinks pour reconstruire l’adresse d’une page ou d’un article et favoriser son référencement. Cependant, leur paramètrage par défaut diffère et il est nécessaire de retrouver le comportement de l’un avec l’autre.

permalinks:
 posts: /:year/:month/:day/:slug

Pour ma part, j’ai privilégié le dérivé :slug pour être en mesure de surcharger la dernière portion de l’URL dans les rares cas où le titre était malformé entre Jekyll et Hugo. Par exemple pour mon article « Tour d’horizon de PgBouncer » où l’apostrophe n’était pas remplacée par le tiret et où je ne voulais pas perdre le référencement, j’ai pu contourner le problème avec l’ajout d’une simple ligne en en-tête du fichier Markdown.

---
title: "Tour d'horizon de PgBouncer"
slug: tour-d-horizon-de-pgbouncer
---

Il m’a également fallu découvrir un paramètre particulier pour ne pas prendre en compte les accents présents dans les titres lors de la génération du slug.

removePathAccents: true

Syndication automatique du contenu

Pour le coup, j’ai bénéficié d’une simplification dans mon projet grâce au support natif et avancé des flux RSS. Alors qu’avec Jekyll, je devais maintenir mes fichiers feed.xml et atom.xml à la racine du projet, j’ai découvert avec Hugo la notion de taxonomie qui permet la classification des articles. La taxonomie regroupe autant les sections, les catégories et les tags, et je trouve ça astucieux.

Imaginons une arborescence très simple avec une page et un article :

content/
├── pages
│   └── a-propos.md
└── posts
 └── 2020-11-18-quelques-outils-meconnus.md

Sans configuration supplémentaire, Hugo générera le contenu statique pour chacun des éléments du projet, en consultant notamment les en-têtes pour extraire les informations categories et tags des articles.

La magie opère avec un ensemble de fichiers index.xml regroupant les éléments d’une même taxonomie.

public/
├── 2020
│   └── 11
│   └── 18
│   └── quelques-outils-meconnus
│   └── index.html
├── categories
│   ├── index.html
│   ├── index.xml
│   └── postgresql
│   ├── index.html
│   └── index.xml
├── index.html
├── index.xml
├── pages
│   ├── a-propos
│   │   └── index.html
│   ├── index.html
│   └── index.xml
└── tags
 └── administration
    ├── index.html
    └── index.xml

La colorisation syntaxique

À ce sujet, j’ai eu une petite surprise avec les balises HTML jusqu’à ce que je me penche sur la documentation. En effet, par défaut, Hugo transforme un bloc de code Markdown en série de balises stylisées.

<div class="highlight">
<pre style="color:#f8f8f2;background-color:#272822;
 -moz-tab-size:4;-o-tab-size:4;tab-size:4">
<code class="language-sql" data-lang="sql">
 <span style="color:#66d9ef">CREATE</span>
 <span style="color:#66d9ef">TABLE</span> people (
 id BIGINT
 <span style="color:#66d9ef">GENERATED</span>
 ALWAYS <span style="color:#66d9ef">AS</span>
 <span style="color:#66d9ef">IDENTITY</span>,
 details jsonb,
 <span style="color:#66d9ef">PRIMARY</span>
 <span style="color:#66d9ef">KEY</span> (id)
 );
</code>
</pre>
</div>

Puisque mon thème original proposait une feuille de style au format SASS spécfiquement pour la colorisation syntaxique, j’ai tenté d’activer l’un des paramètres de Hugo pour utiliser les classes de style plutôt que le comportement ci-dessus.

pygmentsUseClasses: true

Le résultat était inespéré avec les classes reconnus par mes règles CSS.

<div class="highlight">
<pre class="chroma">
<code class="language-sql" data-lang="sql">
 <span class="k">CREATE</span>
 <span class="k">TABLE</span> <span class="n">people</span>
 <span class="p">(</span>
 <span class="n">id</span> <span class="nb">BIGINT</span>
 <span class="k">GENERATED</span>
 <span class="n">ALWAYS</span> <span class="k">AS</span>
 <span class="k">IDENTITY</span><span class="p">,</span>
 <span class="n">details</span> <span class="n">jsonb</span>
 <span class="p">,</span>
 <span class="k">PRIMARY</span> <span class="k">KEY</span>
 <span class="p">(</span><span class="n">id</span><span class="p">)</span>
 <span class="p">);</span>
</code>
</pre>
</div>

Les balises HTML dans le Markdown

Mes fichiers Markdown contenaient des balises HTML pour quelques effets visuels, à savoir des encarts d’avertissement <div>, du surlignage <u> et de très (trop) nombreux exposants <sup> pour mes sources d’articles. Pour cet aspect, Hugo est plus restrictif que Jekyll et ignore tout bonnement les balises dans le rendu de ses pages.

<!-- raw HTML omitted -->

Pour le coup, je n’ai pas cherché s’il existait un paramètre de configuration qui me permettrait de lever la restriction. Ma solution de contournement fut d’utiliser les composants shortcodes pour mes quelques exceptions et la documentation était bien suffisante pour y parvenir sereinement.

Par exemple pour mes encarts, j’ai gagné en facilité de rédaction avec la méthode markdownify fourni par le système de rendu, et je n’écris plus que du Markdown dans mes fichiers !

<!-- layout/shortcodes/message.html -->
<div class="message">{{ .Inner | markdownify }}</div>

<!-- content/posts/exemple.md -->
{\{< message >}\}
Exemple de rendu avec un lien de [documentation][17].
{\{< /message >}\}

Ne pas s’attarder sur les \ qui ne servent qu’à échapper les accolades.

En bref

Au-delà des quelques paramètrages ou réécriture Markdown qui m’ont fait perdre du temps, Hugo présente bien plus de fonctionnalités natives que ne le fait Jekyll. Je dresse une liste non exhausitive des apports qui m’ont convaincu à passer le cap.

Pagination simple et intégrée
Temps estimé de lecture avec la variable .ReadingTime
Génération des pages nettement plus rapide
Portabilité du logiciel avec zéro dépendance système

Pour conclure, je me suis résolu à héberger le projet et le rendu des pages sur GitHub, en suivant les instructions détaillées. La bascule du nom de domaine a ainsi été opérée ce midi et je n’ai plus à me préoccuper de mon ancienne instance VPS ni du certificat à renouveller auprès de Let’s Encrypt.

Quelques outils méconnus

Florent Jardin — Wed, 18 Nov 2020 00:00:00 +0000

Cette semaine, passait sur mon fil d’actualité Twitter une simple URL pointant sur le site https://pgpedia.info. Non loin d’être le seul à l’avoir remarqué, nous en parlions entre collègues pour constater avec surprise que nous ne connaissions pas cette mine d’or d’informations sur PostgreSQL. Après y avoir perdu plusieurs heures, je me suis dit qu’un article sur les quelques utilitaires que j’estime méconnus, pourrait être une bonne conclusion de la semaine.

pg_controldata

Source : https://pgpedia.info/p/pg_controldata.html

Ce premier outil est un must-have pour tous les administrateurs de base de données. Il permet de dresser les principales informations de l’instance, qu’elle soit en cours d’exécution ou arrêtée. Ces dernières sont en partie extraites du fichier pg_control contenu dans le répertoire PGDATA/global, dont notamment, les informations sur les toutes dernières actions du processus checkpointer. On y retrouve aussi quelques configurations fixes et variables de l’instance.

Lorsque j’interviens durant un audit, plusieurs lignes m’interessent pour orienter mes analyses. En voici quelques exemples :

Database cluster state : pour déterminer l’état de l’instance et savoir si j’interviens sur une instance principale ou secondaire. La liste des états est précisée dans le fichier src/include/catalog/pg_control.h (source).

 typedef enum DBState
 {
 DB_STARTUP = 0,
 DB_SHUTDOWNED,
 DB_SHUTDOWNED_IN_RECOVERY,
 DB_SHUTDOWNING,
 DB_IN_CRASH_RECOVERY,
 DB_IN_ARCHIVE_RECOVERY,
 DB_IN_PRODUCTION
 } DBState;

REDO WAL file et REDO location : pour connaître le fichier WAL le plus proche du dernier checkpoint requis pour la récupération des transactions suite à un crash, dans des situations extrêmes où l’archivage n’est pas en place. Dans le cas d’une restauration, ces éléments peuvent me permettre d’identifier le bon fichier backup_label à positionner dans le PGDATA.
Data page checksum version : parfaitement incontournable, cette valeur m’indique si les sommes de contrôle sont actives pour l’instance. Ce mécanisme va permettre de suivre l’évolution des données d’une page en calculant une somme de contrôle (checksum) afin de régulièrement s’assurer qu’aucune corruption matérielle n’ait provoqué un changement de cette page. Par défaut, l’outil initdb ne l’active pas et c’est bien dommage !

pg_waldump

Source : https://pgpedia.info/p/pg_waldump.html

Anciennement connu sous le nom de pg_xlogdump, avant que n’ait eu lieu la campagne de renommage de xlog en wal initiée avec PostgreSQL 10, cet utilitaire permet de parcourir le contenu des journaux de transactions. Jusqu’à présent, je ne m’en sers qu’à des fins pédagogiques, bien qu’il puisse s’avérer redoutable dans un cas de débogage de haute voltige.

BEGIN;
SELECT txid_current();
-- txid_current
-- --------------
-- 1315

CREATE TABLE test(id int);
INSERT INTO test VALUES (1);
COMMIT;

Cette simple transaction provoque plusieurs transformations dans les pages de l’instance, notamment dans le catalogue de la base qui reçoit les instructions SQL, que je cache volontairement dans l’exemple suivant :

$ pg_waldump -p data/pg_wal --start=0/52CA530 --xid=1315

rmgr: Storage desc: CREATE base/16384/24399
rmgr: Standby desc: LOCK xid 1315 db 16384 rel 24399
rmgr: Heap desc: INSERT+INIT off 1 flags 0x00
 blkref #0: rel 1663/16384/24399 blk 0
rmgr: Transaction desc: COMMIT 2020-11-18 11:48:23.229489 CET

L’outil fourni également un vue synthétique avec l’option --stats si l’on souhaite connaître la quantité d’opérations (en nombre et taille en octets) à rejouer lors d’une restauration ou d’une initialisation des données dans le cadre d’une réplication logique.

$ pg_waldump -p data/pg_wal --start=0/52CA530 --end=0/52F8EE8 --stats

Type N Combined size
---- - -------------
Total 243 189643

pg_test_fsync

Source : https://pgpedia.info/p/pg_test_fsync.html

Alors, celui-là, je ne le connaissais pas avant hier ! Il s’avère être un compagnon appréciable lorsqu’on déploit une instance de production sur un système dont on a peu ou pas connaissance des performances d’écriture. Bien qu’à l’origine, cet outil ait été conçu pour comparer les différentes méthodes de synchronisation sur disques et de correctement positionner le paramètre wal_sync_method pour l’instance, il permet de connaître très facilement le débit du disque qui contiendra les journaux de transactions.

$ pg_test_fsync --filename=data/pg_wal/testfile

5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
 open_datasync 1705,357 ops/sec 586 usecs/op
 fdatasync 1624,232 ops/sec 616 usecs/op
 fsync 1155,152 ops/sec 866 usecs/op
 fsync_writethrough n/a
 open_sync 1177,778 ops/sec 849 usecs/op

Compare file sync methods using two 8kB writes:
 open_datasync 830,826 ops/sec 1204 usecs/op
 fdatasync 1631,562 ops/sec 613 usecs/op
 fsync 367,584 ops/sec 2720 usecs/op
 fsync_writethrough n/a
 open_sync 115,385 ops/sec 8667 usecs/op

Compare open_sync with different write sizes:
 1 * 16kB open_sync write 47,843 ops/sec 20902 usecs/op
 2 * 8kB open_sync writes 20,899 ops/sec 47850 usecs/op
 4 * 4kB open_sync writes 126,572 ops/sec 7901 usecs/op
 8 * 2kB open_sync writes 180,532 ops/sec 5539 usecs/op
 16 * 1kB open_sync writes 96,373 ops/sec 10376 usecs/op

Test if fsync on non-write file descriptor is honored:
 write, fsync, close 1395,592 ops/sec 717 usecs/op
 write, close, fsync 1432,511 ops/sec 698 usecs/op

Non-sync'ed 8kB writes:
 write 257485,249 ops/sec 4 usecs/op

J’ai ainsi appris que les méthodes variaient, selon les implémentations de chaque système. Sous Linux, nous aurons par défault la méthode fdatasync alors qu’elle sera open_datasync sous Windows.

Dans la même veine, il existe un autre outil de benchmark nommé pg_test_timing, mais cette fois-ci, pour contrôler que l’horloge du système ne dérive pas lors d’une instruction chronométrée telle que la commande EXPLAIN ANALYZE.

pg_verifybackup

Source : https://pgpedia.info/p/pg_verifybackup.html

Ce petit dernier est arrivé en octobre de cette année avec la sortie de PostgreSQL 13. La communauté a mis à disposition un nouveau fichier appelé « manifeste de sauvegarde » (backup manifest) qui a pour rôle de lister l’ensemble des fichiers contenu dans une sauvegarde physique, ainsi que leur signature par sommes de contrôle.

À présent, l’outil pg_basebackup créé le fichier backup_manifest au sein de son archive, dont la représentation est au format JSON.

{
 "PostgreSQL-Backup-Manifest-Version": 1,
 "Files": [
 {
 "Path": "backup_label",
 "Size": 224,
 "Last-Modified": "2020-11-18 15:25:39 GMT",
 "Checksum-Algorithm": "CRC32C",
 "Checksum": "fc2f12b1"
 },
 ...
 {
 "Path": "postgresql.conf",
 "Size": 27981,
 "Last-Modified": "2020-10-12 10:28:25 GMT",
 "Checksum-Algorithm": "CRC32C",
 "Checksum": "d8ad53d1"
 },
 {
 "Path": "global/pg_control",
 "Size": 8192,
 "Last-Modified": "2020-11-18 15:25:39 GMT",
 "Checksum-Algorithm": "CRC32C",
 "Checksum": "43872087"
 }
 ],
 "WAL-Ranges": [
 {
 "Timeline": 1,
 "Start-LSN": "0/5400028",
 "End-LSN": "0/5400100"
 }
 ],
 "Manifest-Checksum": "f5cf47bdfbfc0641c...5317932c41"
}

Alors que l’outil tier pgbackrest proposait son propre système de contrôle, ce nouveau fichier manifeste pourrait permettre à d’autres solutions de sauvegardes comme pitrery de bénéficier d’une vérification à moindre coût.

En effet, à l’aide de l’outil pg_verifybackup, il est possible de s’assurer qu’une sauvegarde physique n’a pas subi de corruption ou de transformation avant de la restaurer.

$ pg_verifybackup basebackup

error: "global/pg_control.moved" is present on disk but not in the manifest
error: "global/pg_control" is present in the manifest but not on disk

$ mv basebackup/global/pg_control.moved basebackup/global/pg_control
$ pg_verifybackup basebackup
backup successfully verified

Conclusion

La page de documentation « PostgreSQL Server Applications » recense les utilitaires maintenus par la communauté. L’histoire du projet a montré que nombre d’entre eux étaient issus d’une contribution avant d’y être intégrés et démocratisés.

Le site https://pgpedia.info est un excellent complément à la documentation car il retrace avec fidélité les changements survenus pour chaque aspect, méthode, outil présent dans le projet PostgreSQL. Ajoutez-le à vos favoris !