Il arrive que les utilisateurs fassent des bêtises. Ce sont des humains après tout ! Voyons comment réparer l'erreur classique d'une requête destructrice envoyée sur la mauvaise base.

Nous continuons notre aventure au pays des WALs corrompus en imaginant le scenario suivant: La machine a crashé et nous avons perdu l'instance et les données qu'elle comportait. Ce n'est pas un problème, car nous avons des sauvegardes physiques avec archivage des WALs.

Ce que nous ne savons pas, c'est que l'un des WALs sauvegardé est corrompu...

Le langage PL/PgSQL est présent depuis près de 20 ans dans PostgreSQL. Il permet d'étendre le langage SQL par l'ajout d'instructions procédurales.
Jan Wieck, l'auteur du langage, nous propose un profiler.

Après l'installation, ce second article montre l'utilisation du profiler pendant l'exécution d'un test de charge.

Le scenario catastrophe suivant est exploré: crash de l'instance alors que le dernier WAL est corrompu. Cet article propose de tester ce scenario, les moyens de redémarrer l'instance, les conséquences sur les données et enfin comment limiter les risques qu'une telle aventure vous arrive.

Le langage PL/PgSQL est présent depuis près de 20 ans dans PostgreSQL. Il permet d'étendre le langage SQL par l'ajout d'instructions procédurales.
Toutefois, contrairement à une requête SQL que l'on peut analyser avec la commande EXPLAIN, lorsqu'on souhaite optimiser les performances d'une procédure, on ne sait pas forcément par quel bout commencer.

Jan Wieck, créateur du PL/pgSQL, a développé une solution, que nous vous proposons de découvrir.

Première étape : l'installation du profiler de fonctions PL/pgSQL dans PostgreSQL.