Tests on Carnet de découvertes

Halte aux régressions

Florent Jardin — Thu, 21 Apr 2022 00:00:00 +0000

Pour garantir la qualité du code d’un logiciel, rien de mieux que la validation par les tests. Ces derniers peuvent être de différentes natures (fonctionnels, intégration, unitaires, performance, etc.) et permettent de respecter une série d’exigences que s’imposent les développeurs pour maintenir et faire évoluer ledit logiciel dans la bonne direction.

Dans cet article, je souhaite explorer le système de tests tel qu’il est (et a été) implémenté dans PostgreSQL et comment le réemployer dans la rédaction d’une extension communautaire. Si vous ne connaissiez pas l’outil pg_regress, il n’aura plus de secret pour vous !

Aux origines des tests de régression

Avant même l’émergence du plus avancé des systèmes de bases de données open-source du monde que l’on connait, le projet Berkeley POSTGRES disposait déjà d’un répertoire src/regress/regress dans sa dernière version connue. Celui-ci fut définitivement adopté sous la forme de src/test/regress lors de la reprise du projet Postgre95 par les deux étudiants Andrew Yu et Jolly Chen.

Ce n’est pas anodin, car ce répertoire existe encore dans les versions modernes et porte toujours les mêmes responsabilités, à savoir : s’assurer que les fonctionnalités de PostgreSQL ne présentent aucune régression à chaque patch ou nouvelle version majeure. Ce système de test est relativement simple à appréhender et très répandu dans le milieu du développement des logiciels libres.

Il repose sur les fichiers de tests au format SQL et des fichiers de sorties au format OUT. L’astuce consiste à exécuter le code SQL sur une instance en cours d’exécution et de capter la sortie standard dans un fichier de résultat. Pour chaque test (sql), le fichier de résultat (result) est ensuite comparé au résultat attendu du test (expected) à l’aide de la méthode diff.

Ce traitement est réalisé depuis la version 7.1 par l’utilitaire pg_regress.sh. À l’origine, ce dernier était un simple script shell responsable de monter une instance PostgreSQL temporaire au besoin, de rapprocher les fichiers SQL de leurs résultats OUT et de fournir un résumé des tests. Le script fut intégralement remplacé par son équivalent pg_regress réécrit en C à la sortie de la version 8.2, pour faciliter notamment :

La validation des tests sur un environnement Windows sans émulateur de shell tel que mingw
La mise à disposition d’un outil prêt à l’emploi avec l’installation de PostgreSQL, sans les dépendances systèmes requises par l’ancien script
L’implémentation de nouvelles améliorations comme l’exécution concurrente des tests ou un résultat plus conviviale

Lors d’une compilation des binaires d’une version quelconque de PostgreSQL, il est possible de valider tout ou partie des fonctionnalités à l’aide de la commande make check ou make installcheck. La première des deux commandes créée une instance temporaire alors que la seconde va exécuter les tests sur une instance en cours d’exécution.

make check

PATH="tmp_install/var/lib/pgsql-14.2/bin:src/test/regress:$PATH" \
LD_LIBRARY_PATH="tmp_install/var/lib/pgsql-14.2/lib:$LD_LIBRARY_PATH" \
../../../src/test/regress/pg_regress \
 --temp-instance=./tmp_check \
 --inputdir=. --bindir= --dlpath=. \
 --max-concurrent-tests=20 \
 --make-testtablespace-dir \
 --schedule=./parallel_schedule

============== removing existing temp instance ==============
============== creating temporary instance ==============
============== initializing database system ==============
============== starting postmaster ==============
running on port 58082 with PID 24013
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok 165 ms
parallel group (20 tests):
 boolean ... ok 47 ms
 char ... ok 40 ms
 name ... ok 41 ms
 varchar ... ok 38 ms
 text ... ok 34 ms
 int2 ... ok 24 ms
 int4 ... ok 23 ms
 int8 ... ok 55 ms
 oid ... ok 43 ms
 float4 ... ok 60 ms
...
parallel group (2 tests):
 event_trigger ... ok 59 ms
 oidjoins ... ok 119 ms
test fast_default ... ok 71 ms
test stats ... ok 620 ms

============== shutting down postmaster ==============
============== removing temporary instance ==============
...
=======================
 All 210 tests passed.
=======================

Tester son extension avec PGXS

En plusieurs années, l’outil pg_regress s’est étendu aux fonctionnalités annexes du projet PostgreSQL, comme les langages embarqués (plpgsql, plperl, etc.) ou les contributions communautaires.

Le système PGXS propose aux membres de la communauté d’enrichir leurs Makefile avec des règles de compilation, d’installation et de validation par pg_regress. Dans un projet, il est ainsi recommandé d’inclure les directives du PGXS pour bénéficier de la règle installcheck responsable des tests.

Prenons l’exemple de la contribution pgstattuple avec la définition de son Makefile. Ce dernier contient les quelques variables nécessaires pour la compilation et l’installation, puis inclut les règles pgxs.mk si le système est utilisé.

# contrib/pgstattuple/Makefile
REGRESS = pgstattuple

ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
else
subdir = contrib/pgstattuple
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif

Avec cette configuration par défaut, l’outil pg_regress part à la recherche des fichiers sql/ dans le répertoire courant, et les exécute sur l’instance pour ensuite comparer ses résultats avec les fichiers expected/. Le contenu du fichier expected/pgstattuple.out peut être consulté directement dans le code source de PostgreSQL.

pgstattuple
├── expected
│   └── pgstattuple.out
├── results
│   └── pgstattuple.out
└── sql
 └── pgstattuple.sql

Lançons les tests de l’extension avec le système PGXS :

cd contrib/pgstattuple
make USE_PGXS=1 install installcheck

./lib/pgxs/src/makefiles/../../src/test/regress/pg_regress \
 --inputdir=./ --bindir='./bin' \
 --dbname=contrib_regression pgstattuple

(using postmaster on Unix socket, default port)
============== dropping database "contrib_regression" ==============
DROP DATABASE
============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test pgstattuple ... ok 167 ms

=====================
 All 1 tests passed.
=====================

Pensez-y !

Vous souhaitez développer votre propre extension pour révolutionner PostgreSQL ? Pensez à écrire vos tests avec le framework PGXS ! La documentation est très fournie à ce sujet pour prendre en main les variables d’environnement. De plus, depuis la version PostgreSQL 9.4, il est possible de bénéficier de standard TAP pour rédiger vos tests.

Les extensions sont nombreuses et ce n’est jamais une mauvaise idée de s’inspirer des contributions maintenues dans le projet PostgreSQL. Je recommande également la série d’articles rédigée par Manuel Kniep pour comprendre le processus complet de l’écriture d’une extension ou la conférence de Lætitia Avrot sur l’extension pgwaffles créée à l’occasion du FOSDEM 2021.

Écrire ses tests unitaires en SQL

Florent Jardin — Thu, 14 May 2020 17:30:00 +0200

Je ne suis qu’un piètre développeur et je n’écris pas de tests unitaires. En réalité, ce n’est ni ma spécialité ni mon cœur de métier. Et pourtant, ma curiosité m’a mené à découvrir bien tardivement la mouvance TDD dans la conception logicielle et la rigueur d’écrire chaque test avant l’implémentation d’une fonctionnalité.

Ce fut par hasard et avec grand étonnement, que je suis tombé sur l’extension pgTAP il y a plusieurs mois, et l’idée de la mettre en application sur une instance PostgreSQL me hantait. Je vous propose dans cet article d’aborder ce framework de tests avec un cas d’usage amusant.

Dans le cadre de ma rapide démonstration, j’utilise un conteneur docker dont le Dockerfile provient des travaux de Damien Clochard.

Appliquons une démarche de développement par les tests

En France, le mois de mai dispose du plus grand nombre de jours fériés, fait qu’apprécient grandement les salariés. Comment détermine-t-on en avance la liste des jours fériés d’une année ? Le jour courant est-il ou non férié ? Pourrait-on appliquer une contrainte de colonne pour qu’aucune date fériée ne soit insérée dans une table en base de données ?

Ces questions peuvent être celles qui émergent de la tête d’un développeur ou d’un membre de son équipe, et sont ainsi les premières étapes de la conception logicielle avec la rédaction de ces dernières sous la forme de tests unitaires. Le principe ultime à respecter dans un développement orienté tests (TDD) repose sur les quelques règles suivantes :

Écrire un test qui échoue
Écrire l’implémentation minimale et s’assurer que le test réussisse
Réusiner l’ensemble du code (… oui, c’est la traduction du terme refactorer)

Fort de vouloir respecter cette boucle vertueuse, je rédige dans un fichier test.sql mon premier test unitaire. Il s’agit là d’utiliser la méthode has_function() fournie par pgTAP pour m’assurer qu’une fonction est présente dans la base de données.

-- Nous démarrons une transaction pour l'annuler en fin de test
BEGIN
SELECT plan(1);

-- premier tests
SELECT has_function(
 'is_public_holiday',
 array[ 'date' ],
 'Function is_public_holiday(date) should exist'
);

-- On affiche la synthèse de l'exécution des tests et on annule la transaction
SELECT * FROM finish();
ROLLBACK;

À travers mon conteneur, je lance la commande pg_prove nécessaire pour l’extension et l’exécution des tests renseignés dans le fichier test.sql. Je constate bel et bien un test en erreur : la fonction is_public_holiday n’existe pas encore dans mon cycle de développement.

$ docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. 1/1
# Failed test 1: "Function is_public_holiday(date) should exist"
# Looks like you failed 1 test of 1
test.sql .. Failed 1/1 subtests

Test Summary Report
-------------------
test.sql (Wstat: 0 Tests: 1 Failed: 1)
 Failed test: 1
Files=1, Tests=1, 1 wallclock secs
 ( 0.04 usr 0.01 sys + 0.04 cusr 0.01 csys = 0.10 CPU)
Result: FAIL

Je m’attèle donc à la rédaction de ma fonction, que j’ajoute dans un nouveau fichier is_public_holiday.sql. La méthode TDD implique qu’un effort minimal soit fourni pour passer le test.

CREATE OR REPLACE FUNCTION is_public_holiday(day date)
 RETURNS boolean LANGUAGE plpgsql
AS $$
BEGIN
 RETURN false;
END;
$$;

$ docker exec -it pgdemo psql -U postgres -f is_public_holiday.sql
CREATE FUNCTION

$ docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs
 ( 0.02 usr 0.01 sys + 0.05 cusr 0.01 csys = 0.09 CPU)
Result: PASS

Sommes-nous un jour férié ?

Bien.

Pour dépasser le syndrôme de la page blanche, pourquoi ne pas tenter de s’assurer que notre fonction retourne parfaitement la valeur true ou false selon le jour qu’on lui passerait en paramètre ? Écrivons un test pour la date du 1^er mai 2020 et un autre pour celle du 12 mai 2020.

-- [...]
SELECT is(
 is_public_holiday('2020-05-01'::date),
 true,
 '2020-05-01 is a public holiday'
);

SELECT is(
 is_public_holiday('2020-05-12'::date),
 false,
 '2020-05-12 is not a public holiday'
);
--- [...]

Lançons à présent les tests.

$ docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. 1/3
# Failed test 2: "2020-05-01 is a public holiday"
# have: false
# want: true
# Looks like you failed 1 test of 3
test.sql .. Failed 1/3 subtests

Test Summary Report
-------------------
test.sql (Wstat: 0 Tests: 3 Failed: 1)
 Failed test: 2
Files=1, Tests=3, 1 wallclock secs
 ( 0.02 usr 0.02 sys + 0.05 cusr 0.01 csys = 0.10 CPU)
Result: FAIL

L’un de nos tests est donc en erreur, il faut apporter une évolution à notre fonction principale pour tâcher d’y remédier. Je suis partisan du moindre effort, une comparaison du mois et du jour de notre date suffira. Je me permets donc le luxe d’un IF au sein du code.

BEGIN
 IF extract(month from day) = 5 AND
 extract(day from day) = 1
 THEN
 RETURN true;
 END IF;

 RETURN false;
END;

C’est simple, efficace… et subjectivement très mauvais. Le résultat escompté est atteint avec 100% des tests réussis. Mais je commence à entrevoir des problèmes de maintenance de code. Poussons les tests plus loin.

$ docker exec -it pgdemo psql -U postgres -f is_public_holiday.sql
CREATE FUNCTION

$ docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. ok
All tests successful.
Files=1, Tests=3, 0 wallclock secs
 ( 0.03 usr 0.00 sys + 0.04 cusr 0.02 csys = 0.09 CPU)
Result: PASS

Un peu de réusinage, parbleu !

Non content d’avoir trouvé une solution fiable pour les jours fériés fixes, je poursuis avec un nouveau test pour le 1^er janvier.

SELECT is(
 is_public_holiday('2020-01-01'::date),
 true,
 '2020-01-01 is a public holiday'
);

Et j’ajoute au code de ma fonction is_public_holiday, une nouvelle condition IF. Je me retrouve avec cette immondice, qui me rappelle certaines règles logiques issues de (trop) longues procédures stockées PL/SQL, que j’eus croisées dans une précédente vie.

BEGIN
 IF extract(month from day) = 1 AND
 extract(day from day) = 1
 THEN
 RETURN true;
 END IF;

 IF extract(month from day) = 5 AND
 extract(day from day) = 1
 THEN
 RETURN true;
 END IF;

 RETURN false;
END;

Mes tests passent correctement mais il est aproprié de s’arrêter sur l’un des principes du développement TDD : le refactoring, ou l’art de simplifier le code pour le rendre plus lisible et maintenable. L’idée est donc de proposer une réécriture de notre fonction is_public_holiday sans altérer l’état des tests. C’est parti !

-- Type month_day
DROP TYPE IF EXISTS month_day;
CREATE TYPE month_day AS (month int, day int);

-- Function is_public_holiday(date)
CREATE OR REPLACE FUNCTION is_public_holiday(day date)
 RETURNS boolean LANGUAGE plpgsql
AS $$
DECLARE
 m int := extract(month from day);
 d int := extract(day from day);
 holidays month_day[] := array[
 (1,1), (5,1)
 ];
BEGIN
 RETURN (m,d) = ANY (holidays);
END;
$$;

Dans cette version améliorée, je prends la décision de créer le type month_day qui représente le couple mois/jour afin de réaliser des comparaisons ensemblistes avec le mot clé ANY fourni par le standard SQL. La variable holidays devient alors mon tableau de références contenant les jours fériés fixes de l’année.

Mes tests restent inchangés pour les dates de 1^er janvier et du 1^er mai.

$ docker exec -it pgdemo psql -U postgres -f is_public_holiday.sql
DROP TYPE
CREATE TYPE
CREATE FUNCTION

$ docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. ok
All tests successful.
Files=1, Tests=4, 1 wallclock secs
 ( 0.05 usr 0.00 sys + 0.06 cusr 0.01 csys = 0.12 CPU)
Result: PASS

Pour m’assurer que tous les jours fériés fixes restants dans une année soient bien testés, je peux proposer un nouveau test qui les englobe. Par exemple, pour l’année 2020 :

SELECT is(
 is_public_holiday(x::date),
 true,
 format('%s is as public holiday', x)
) FROM unnest(array[
 '2020-05-08', '2020-07-14', '2020-08-15',
 '2020-11-01', '2020-11-11', '2020-12-25'
 --, '2020-12-26' -- si vous vivez en Alsace-Moselle
]) x;

Sans trop de difficulté, et parce que nous avions réalisé avec succès la phase de réusinage du code, je peux ajouter l’implémentation des nouveaux jours fériés dans ma fonction et passer les tests avec succès.

DECLARE
 m int := extract(month from day);
 d int := extract(day from day);
 holidays month_day[] := array[
 (1,1), (5,1), (5,8), (7,14),
 (8,15), (11,1), (11,11), (12,25)
 --, (12,26) -- si vous vivez en Alsace-Moselle
 ];
BEGIN
 RETURN (m,d) = ANY (holidays);
END;

Les jours incroyables de la mort du Christ

Si vous avez bien suivi, il ne manque plus que l’implémentation des fameux jours du lundi de Pâques, du jeudi de l’Ascension et du lundi de Pentecôte, voire du Vendredi Saint pour mes lecteurs assidus du Grand Est. Ces jours religieux ont la grande particularité d’être différents chaque année mais relativisons rapidement, les trois derniers dépendent de la date du lundi de Pâques. Rédigeons dès à présent les tests avant d’attaquer la partie épineuse de mon aventure.

Pour la rédaction de ces tests, je souhaiterais m’assurer qu’une série de lundis de Pâques piochés au cours du dernier siècle soient bien identifiés comme des jours fériés par ma fonction.

SELECT is(
 is_public_holiday(x::date),
 true,
 format('%s is an easter monday', x)
) FROM unnest(array[
 '1931-04-06', '1945-04-02', '1968-04-15',
 '1989-03-27', '2000-04-24', '2020-04-13'
]) x;

Je ne vous le cache pas, j’ai découvert le calcul du jour de Pâques il y a plusieurs années, alors même que je devais écrire une fonction en PL/pgSQL selon la méthode de Gauss pour un système de planification embarqué dans une base PostgreSQL. Avec cet article, c’est l’occasion de la dépoussiérer et lui donner l’occasion d’être mise en lumière. J’ajoute à mon code initial, la définition de cette nouvelle fonction qui prendra une année en paramètre, requise pour déterminer « le dimanche qui suit la première pleine lune du printemps ».

CREATE OR REPLACE FUNCTION easter_date(year int)
 RETURNS date LANGUAGE plpgsql
AS $$
DECLARE
 g integer := year % 19;
 c integer := year / 100;
 h integer := (c - c/4 - (8*c+13)/25 + 19*g + 15) % 30;
 i integer := h - h/28 * (1 - h/28 * (29/(h + 1)) * (21 - g)/11);
 j integer := (year + year/4 + i + 2 - c + c/4) % 7;
 l integer := i - j;
 m integer := 3 + (l + 40)/44;
 d integer := l + 28 - 31 * (m/4);
BEGIN
 RETURN format('%s-%s-%s', year, m, d);
END;
$$;

Il s’agit à présent d’intégrer ce calcul dans notre fonction is_public_holiday et satisfaire la comparaison avec nos dates de tests. Nous souhaitons connaître la date du lundi de Pâques, et non celle du dimanche fournie par l’algorithme précédent.

DECLARE
 y int := extract(year from day);
 m int := extract(month from day);
 d int := extract(day from day);

 easter date := easter_date(y);
 holidays month_day[] := array[
 (1,1), (5,1), (5,8), (7,14),
 (8,15), (11,1), (11,11), (12,25)
 ];
BEGIN
 IF (m,d) = (
 extract(month from easter+1),
 extract(day from easter+1)
 )
 THEN
 RETURN true;
 END IF;

 RETURN (m,d) = ANY (holidays);
END;

Encore une fois, j’implémente cette nouvelle règle de comparaison avec le minimum d’efforts et un bloc IF comme la fois passée. Les tests se réalisent sans accroc pour la sélection préalable des lundis de Pâques.

# docker exec -it pgdemo psql -U postgres -f is_public_holiday.sql
DROP TYPE
CREATE TYPE
CREATE FUNCTION
CREATE FUNCTION
# docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. ok
All tests successful.
Files=1, Tests=16, 0 wallclock secs
 ( 0.04 usr 0.01 sys + 0.05 cusr 0.00 csys = 0.10 CPU)
Result: PASS

Je poursuis les étapes itératives de développement, à savoir : écrire un test en erreur, écrire l’implémentation, simplifier le code. J’en viens à écrire une séries de tests pour les dates de l’Ascension et de la Pentecôte.

SELECT is(
 is_public_holiday(x::date),
 true,
 format('%s is as ascension day', x)
) FROM unnest(array[
 '1921-05-05', '1940-05-02', '1960-05-26',
 '1998-05-21', '2011-06-02', '2020-05-21'
]) x;

SELECT is(
 is_public_holiday(x::date),
 true,
 format('%s is pentecost', x)
) FROM unnest(array[
 '1910-05-16', '1928-05-28', '1955-05-30',
 '1984-06-11', '2003-06-09', '2020-06-01'
]) x;

Plutôt que d’employer une succession de IF pour valider ces nouvelles règles, je réécris la fonction is_public_holiday pour enrichir mon tableau de références holidays avec trois nouvelles dates, déterminées à partir du jour de Pâques. L’astuce consiste à ajouter +1 pour obtenir le lundi de Pâques, +39 pour le jeudi de l’Ascension et +50 pour le lundi de la Pentecôte. (Pour les régions exotiques, le Vendredi Saint aura lieu 2 jours avant Pâques.)

DECLARE
 y int := extract(year from day);
 m int := extract(month from day);
 d int := extract(day from day);
 h month_day;

 easter date := easter_date(y);
 holidays month_day[] := array[
 (1,1), (5,1), (5,8), (7,14),
 (8,15), (11,1), (11,11), (12,25)
 ];
BEGIN
 FOR h IN (
 SELECT extract(month from easter+i) "month",
 extract(day from easter+i) "day"
 FROM unnest(array[1, 39, 50]) i
 ) LOOP
 holidays := array_append(holidays, h);
 END LOOP;

 RETURN (m,d) = ANY (holidays);
END;

Et cette fois-ci, nous sommes assurés par nos tests que l’ensemble des jours fériés seront correctement identifiés par la fonction.

$ docker exec -it pgdemo pg_prove -U postgres test.sql
test.sql .. ok
All tests successful.
Files=1, Tests=28, 0 wallclock secs
 ( 0.04 usr 0.00 sys + 0.04 cusr 0.02 csys = 0.10 CPU)
Result: PASS

La contrainte d’intégrité pour les jours fériés

Pour en finir avec une dernière réflexion, le framework pgTAP peut également être employé pour réaliser des tests de non régression au niveau du modèle de données. C’est même sa fonction première avec une série de méthodes permettant de questionner le catalogue système de la base.

Voyons quelques unes d’entre-elles avec les exemples suivants.

-- Contrôler la présence et bonne définition d'un type
SELECT has_type('month_day');
SELECT col_type_is('month_day', 'month', 'integer');
SELECT col_type_is('month_day', 'day', 'integer');

-- Contrôler qu'une contrainte est bien définie sur une table
CREATE TABLE t (
 id int, task varchar,
 planned date check (not is_public_holiday(planned))
);
SELECT col_has_check('t', 'planned');

-- Contrôler qu'une erreur d'intégrité est bien levée
SELECT throws_ok(
 $$insert into t values (1, 'travailler', '2020-05-21')$$,
 23514 -- code d'erreur check_violation
);

Le framework existe depuis 2008 et continue son bonhomme de chemin auprès de la communauté. Ce n’est clairement pas un outil pour un environnement de production, mais peut s’avérer un bel atout pour les chaînes de développement continu afin de s’assurer que les migrations applicatives n’oublient pas un objet ou une relation dans son livrable, ou pire, n’en suppriment pas par erreur.

J’espère que l’exemple léger sélectionné par mes soins vous aura plu, et vous aura permis de découvrir comme moi un framework de tests orienté SQL. Si vous souhaitez parcourir les fichiers de ma démonstration, ils sont en accès libre sur gist.github.com/fljdin.

Jette ton instance à la poubelle

Florent Jardin — Thu, 20 Jun 2019 13:00:00 +0100

À des fins de qualité ou de formation, il est très souvent nécessaire d’avoir une instance PostgreSQL d’une version particulière sur un environnement non critique, que l’on peut malmener à souhait et à l’infini. La communauté Debian propose l’outil pg_virtualenv (manpage) pour démarrer une instance jettable, tout à fait compatible avec des tests de régression ou l’exécution de scripts lors d’une démonstration.

Le package postgresql-common est une des dépendances du package postgresql toutes versions confondues. Par exemple, sur un Ubuntu 16.04 pour la version 11, on peut lister les packages qui seront installés en plus de notre instance :

$ sudo apt-cache depends postgresql-11
 ...
 Depends: postgresql-client-11
 postgresql-client-11:i386
 Depends: postgresql-common
 Depends: ssl-cert
 ...

Ce package met donc à disposition une série de scripts – dont le préfixe est pg_ – qui s’appuie sur la détection automatique des binaires de la version la plus récente installée, en parcourant le répertoire /usr/lib/postgresql. On retrouve ainsi les script Perl de gestion de clusters propres aux installations sous Debian/Ubuntu : pg_lscluster, pg_upgradecluster ou pg_ctlcluster.

$ sudo dpkg-query -L postgresql-common
...
/usr/bin/pg_virtualenv
/usr/bin/pg_upgradecluster
/usr/bin/pg_renamecluster
/usr/bin/pg_lsclusters
/usr/bin/pg_dropcluster
/usr/bin/pg_ctlcluster
/usr/bin/pg_createcluster
/usr/bin/pg_conftool
/usr/bin/pg_config
package diverts others to: /usr/bin/pg_config.libpq-dev
...

Le script pg_virtualenv est la seule exception dans cette série. Il est écrit en bash et s’appuie sur la commande mktemp (manpage) pour isoler l’utilisateur afin qu’il n’interfère avec aucune instance présente sur le serveur. Pour cela, l’outil surchage plusieurs variables d’environnement (PG_CLUSTER_CONF_ROOT, PGSYSCONFDIR, LOGDIR, PWFILE, PGUSER, PGPASSWORD) avant d’initialiser une nouvelle instance via le script pg_createcluster.

$ bash -x /usr/bin/pg_virtualenv
...
++ mktemp -d -t pg_virtualenv.XXXXXX
+ WORKDIR=/tmp/pg_virtualenv.XjpJku
+ PG_CLUSTER_CONF_ROOT=/tmp/pg_virtualenv.XjpJku/postgresql
+ PGUSER=fjardin
+ PGSYSCONFDIR=/tmp/pg_virtualenv.XjpJku/postgresql-common
+ mkdir /tmp/pg_virtualenv.XjpJku/postgresql-common /tmp/pg_virtualenv.XjpJku/log
+ PWFILE=/tmp/pg_virtualenv.XjpJku/postgresql-common/pwfile
+ LOGDIR=/tmp/pg_virtualenv.XjpJku/log
++ pwgen 20 1
+ PGPASSWORD=giul8aih3ieviFeef1sh
+ echo giul8aih3ieviFeef1sh
+ pg_createcluster -d /tmp/pg_virtualenv.XjpJku/data/11/regress
 -l /tmp/pg_virtualenv.XjpJku/log/postgresql-11-regress.log
 --pgoption fsync=off --start 11 regress --
 --username=fjardin --pwfile=/tmp/pg_virtualenv.XjpJku/postgresql-common/pfile
 --nosync

Creating new PostgreSQL cluster 11/regress ...
/usr/lib/postgresql/11/bin/initdb --data-checksums --encoding=UTF8
 --username=postgres --pwfile=/var/lib/postgresql/.pwfile
 -D /tmp/pg_virtualenv.XjpJku/data/11/regress --auth-local peer --auth-host md5
 --username=fjardin --pwfile=/tmp/pg_virtualenv.XjpJku/postgresql-common/pwfile
 --nosync
The files belonging to this database system will be owned by user "fjardin".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are enabled.

fixing permissions on existing directory
 /tmp/pg_virtualenv.XjpJku/data/11/regress ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok

Sync to disk skipped.
The data directory might become corrupt if the operating system crashes.

Success. You can now start the database server using:

 pg_ctlcluster 11 regress start

Ver Cluster Port Status Owner Data directory
11 regress 5432 online fjardin /tmp/pg_virtualenv.PEkXHz/data/11/regress

Log file
/tmp/pg_virtualenv.PEkXHz/log/postgresql-11-regress.log

Et voilà ! Tous les éléments suffisants à l’administration de ce cluster temporaire regress se situent soit dans les variables d’environnement, soit dans le fichier pg_service.conf de l’espace temporaire. Les bases sont donc disponibles par l’utilisateur courant jusqu’à ce que ce dernier quitte l’environnement d’exécution par la commande exit.

$ env | grep PG
PGPORT=5432
PGUSER=fjardin
PGPASSWORD=oChuaWa8cho6uK5Goono
PGDATABASE=postgres
PGHOST=localhost
PGSYSCONFDIR=/tmp/pg_virtualenv.PEkXHz/postgresql-common
PG_CLUSTER_CONF_ROOT=/tmp/pg_virtualenv.PEkXHz/postgresql
PG_CONFIG=/usr/lib/postgresql/11/bin/pg_config

$ cat $PGSYSCONFDIR/pg_service.conf
[11]
host=localhost
port=5432
dbname=postgres
user=fjardin
password=oChuaWa8cho6uK5Goono

$ exit
Dropping cluster 11/regress ...

N’étant pas (encore) un féru de développement et du TDD pour employer l’outil dans des tests de régressions, j’utilise la commande sur un poste Debian/Ubuntu ou sur Windows WSL de la même famille pour disposer d’une instance prête en quelques secondes. Pour obtenir un tel résultat, il suffit d’ajouter le bon repository officiel et de lancer l’installation dans cet ordre.

sudo apt-get install -y postgresql-common

sudo mkdir /etc/postgresql-common/createcluster.d
echo create_main_cluster = false | \
 sudo tee /etc/postgresql-common/createcluster.d/ignore_create_cluster.conf

sudo apt-get install -y postgresql-10 postgresql-11
sudo systemctl disable postgresql.service

De cette façon, nous disposons rapidement des packages à jour pour les versions 10 et 11 sur notre distribution. Les possibilités sont donc nombreuses, comme illustrer ses propos lors de présentations ou de formations devant un public, valider le contenu d’un script SQL livré par son client sur une version spécifique ou simplement découvrir les nouvelles fonctionnalités d’une version majeure fraîchement compilée ou disponible sur le repository !