Il était une fois, dans une salle serveur lointaine, entourée de verre blindé et de béton armé, une base PostgreSQL tellement confinée, tellement isolée, qu’elle ne pouvait que rêver du cloud.
Pas de réseau.
Pas d’USB.
Aucun stockage externe accessible en écriture.
Juste un clavier, un écran, et le bourdonnement des filtres à air de qualité industrielle.
Ce n’était pas un simple environnement “air-gapped”. C’était une zone d’exfiltration zéro, avec une sécurité opérationnelle si rigoureuse qu’on aurait cru qu’elle protégeait des secrets d’État — ou pire, un système bancaire des années 80.
Et pourtant, dans cet oubli numérique, une question demeurait :
Comment sauvegarder une base PostgreSQL sans jamais extraire un seul fichier ?
Notre client ne voulait pas juste une sauvegarde. Il en avait besoin. La crainte n’était pas le vol, mais la perte totale : une carte mère qui meurt en silence, enfermant les données à jamais dans sa cage de verre. Et dans ce cas, casser le mur à la masse n’est pas un plan de reprise d’activité très élégant.
Nous avons envisagé toutes les options :
psql ? Beaucoup trop verbeux.Et puis, l’illumination : les QR codes.
Et si on faisait un pg_dump de la base…
…en QR codes…
…affichés à l’écran…
…filmés par une caméra haute fréquence…
…puis reconstitués image par image à l’extérieur ?
C’était absurde. Donc forcément prometteur.
pg_dump : la version pixeliséeL’outil adoré pg_dump de PostgreSQL est modulaire. On l’a donc enrichi d’un nouvel “archiver” : --format=qrcode.
Voici le fonctionnement :
stdout.Pas de macros. Pas de tricherie. Juste des photons et des images.
Une fois la vidéo extraite du cube de verre :
pg_dump.sql complet.Et voilà : la base renaît — entièrement exportée sans transfert numérique.
Rien que de la lumière et des lentilles.
Ce n’est pas juste une anecdote technique — c’est une preuve que la souplesse de PostgreSQL s’étend jusqu’à l’absurde. Les environnements ultra-sécurisés ne sont pas rares : défense, finance, infrastructures critiques… Et quand les outils classiques ne suffisent plus, l’architecture extensible de PostgreSQL permet d’innover, même en milieu extrême.
Chez Data Bene, on vit pour ce genre de défi. Optimiser les plans d’exécution ou imaginer des méthodes d’exfiltration qui ressemblent à de l’espionnage, c’est notre terrain de jeu.
Envie d’essayer ? Écrivez-nous — on adore les sauvegardes bizarres.
Et si jamais vous pensez à utiliser pg_restore en spectacle laser, appelez-nous. On est curieux.
Le programme comptait 101 conférences techniques animées par 105 intervenants. La majorité des sessions étaient en mandarin, avec un track anglophone proposé en traduction simultanée. Vous pouvez consulter le programme complet sur IvorySQL.io et retrouver les replays sur Weibo via ce lien.
Nous étions un petit groupe de la communauté internationale présents, dont Grant Zhou qui assure entre autre la liaison et la collaboration avec l’association PostgreSQL en Chine et dans le reste du monde.
Sur le plan technique, le contenu était dense et particulièrement intéressant. J’ai retenu notamment :
La présentation d’Alena Rybakina sur le planificateur de requêtes PostgreSQL et les stratégies pour contourner certaines limites.
Un focus clair et concret sur Patroni (Haute-Disponibilité) par Alexander Kukushkin et Polina Bungina.
Florentz Tselai a présenté 2 sujets en appliquant ses préceptes: simplicité efficacité, sur l’utilisation de «l’IA» avec PostgreSQL et la gestion des données avec comme support Sun Tzu et les 36 stratagèmes.
Également une très bonne introduction à Bazel et son utilisation pour Monogres (à découvrir bientôt) présenté avec énergie par Alvaro Hernandez.
Monogres est une initiative très intéressante qui doit permettre de renforcer le contrôle de la supply chain logicielle, un thème majeur dans l’IT de nos jours. Et j’y ai aussi vu une très belle occasion d’offrir une vitrine a des variations de PostgreSQL avec des fonctionnalités et des correctifs dont l’inclusion dans PostgreSQL lui-même même ou le backport dans des version majeures précédentes n’est pas toujours possible.
Michael Meskes avait l’honneur d’une conférence plénière pour un sujet qui le mérite largement: « From Code to Commerce: Open Source Business Models Today », une keynote sur l’open-source et les logiciels libres, appliqués à l’écosystème PostgreSQL.
Mon collègue Andrea a présenté les évolutions et les tendances des entreprises pour transiter vers IvorySQL et PostgreSQL
Pour ma part, j’ai présenté linux PSI dans le contexte PostgreSQL.
Comme tout est en streaming, je vous encourage à aller explorer et visionner les sujets qui vous intéressent. Il y a ausi des conférences en anglais pré-enregistrées mais j’avoue avoir profité des créneaux pour échanger avec des participants.
En apparté des conférences, j’ai eu la chance de rencontrer plusieurs membres de la communauté PostgreSQL chinoise très réputés pour leur implication dans le succès de PostgreSQL localement. J’ai eu aussi l’occasion d’en apprendre d’avantage sur Cloudberry, en remplacement de Greenplum, merci Dianjin Wang!
Pour Data Bene s’était également un moment prévu pour rencontrer l’équipe en charge d’IvorySQL, basée en grande partie dans le Shandong, la province où se trouve Jinan, ville hôte des conférences. Ivory est un projet auquel nous participons activement et qui permet aux entreprises de s’affranchir d’Oracle «en douceur». C’est un sujet important pour nos clients et qui occupe un place prépondérante dans notre partenariat avec Highgo: ils portent ce projet depuis plusieurs années déjà et nous voulons permettre aux entreprises européenes d’en profiter avec un accompagnement et expertise adaptée.
Les conférences étaient très bien organisées et l’acceuil formidable, le «Social Event» au «beer garden» local parfaitement adapté à la chaleur de Jinan fin juin!
Vu le programme des conférences j’ai amèrement regreté de ne rien comprendre (Il y avait 1 track en Anglais et 5 en Mandarin) … mais il se dit déjà que l’an prochain les conférences en Mandarin pourraient peut être être traduites (en anglais), et la date avancée en Mai pour profiter d’un climat plus doux.
Il y a tellement à y apprendre que j’y retournerai avec grand plaisir.
]]>Les statistiques (au sens large: compteurs de supervision, métriques I/O, et estimations pour le planificateur / optimiseur) sont au cœur à la fois de l’optimisation de performance et des décisions internes de PostgreSQL. Des statistiques transparentes, fiables et manipulables permettent entre autres aux DBAs d’adresser directement l’efficacité de PostgreSQL, et donnent aux «extensions» la possibilité d’améliorer l’expérience utilisateur.
Cela dit, le système historique de statistiques de PostgreSQL n’était pas exempt de frictions: capacité limitée à réinitialiser les statistiques des relations, métriques exprimées dans des unités pas toujours alignées avec les besoins utilisateurs, absence d’API C pour utiliser le moteur de statistiques cumulatives de PostgreSQL. PostgreSQL 18 répond directement à ces préoccupations.
Voici un résumé des améliorations clés.
Bien que les statistiques soient extrêmement utiles, leur collecte peut consommer du temps et des ressources. PostgreSQL 18 introduit un point important: avec l’élargissement du spectre des métriques collectables, la taille maximale de la table de hachage a été augmentée. Gardez cela à l’esprit, surtout si vous concevez des systèmes à grande échelle avec des architectures «un ensemble de tables par client»: on a constaté que la limite de 1 Go pouvait être atteinte avec quelques millions de tables.
Voici les nouvelles fonctionnalités majeures ou les améliorations concernant les statistiques et la supervision.
De manière générale, pg_stat_io rapporte désormais l’activité I/O en octets plutôt qu’en pages, ce qui est plus pratique pour l’analyse. De plus, les statistiques WAL y ont été déplacées depuis pg_stat_wal, offrant ainsi une vue unique et complète.
pg_upgrade est désormais capable de conserver les statistiques de l’optimiseur, supprimant la nécessité de relancer un ANALYZE complet pour obtenir de bons plans de requêtes après une montée de version: une avancée très attendue pour les grandes bases!
Attention toutefois: les statistiques personnalisées ajoutées par une extension ainsi que celles créées avec CREATE STATISTICS ne sont pas conservées.
Vous voudrez sûrement examiner les nouvelles options de vacuumdb (--missing-stats-only) pour n’analyser que ce qui est nécessaire.
Dans la même veine, l’option --[no-]statistics a été ajoutée à pg_dump, pg_dumpall, et pg_restore.
Il est désormais plus simple d’évaluer l’effort de maintenance sur les objets, puisque le temps total passé dans les opérations VACUUM et ANALYZE (y compris
automatiques) est rapporté dans pg_stat_all_tables et ses variantes.
Un nouveau GUC à ne pas oublier: track_cost_delay_timing. Il collecte le temps passé à dormir (suite aux opérations retardées) pour VACUUM et ANALYZE. Très intéressant, mais comme les autres GUC track_io*, il multiplie les appels à l’horloge système, ce qui peut provoquer un impact sévère sur certaines plateformes. Toujours vérifier avec un outil comme pg_test_timing pour s’assurer que votre système peut le supporter!
Plus de questions sur l’activité du checkpointer grâce à pg_stat_checkpointer. Le nouvel attribut num_done indique le nombre de checkpoints terminés. Vous pouvez aussi savoir quel type de buffers a été écrit grâce à slru_written, et buffers_written qui ne concerne désormais que shared_buffers: auparavant, journal et vue n’affichaient pas les mêmes totaux, car un compteur SLRU existait dans un cas mais pas dans l’autre.
Envie d’en savoir plus sur l’I/O traité par un backend (PID) ? Appelez pg_stat_get_backend_io(int) et vous obtiendrez une sortie similaire à la vue pg_stat_io, mais pour ce processus. Pour les stats WAL de ce PID: utilisez pg_stat_get_backend_wal(int).
De nouveaux attributs parallel_workers_to_launch et parallel_workers_launched apparaissent dans pg_stat_database. Le ratio permet de savoir si nous avons assez de slots pour les workers parallèles.
Changements intéressants dans pg_stat_statements: plus de requêtes seront regroupées sous le même identifiant. Par exemple, les
motifs IN (1,2,3, ...) n’utiliseront que la première et la dernière constante. Un changement plus contre-intuitif concerne le nom de table utilisé dans une requête: seul le nom est pris en compte, pas le schéma ni l’OID de relation. Cela permet de suivre les tables supprimées ou recréées, mais cela peut aussi regrouper les stats de tables sans lien ayant simplement le même nom. Pour séparer les stats de tables homonymes, il faudra les aliaser dans les requêtes (FROM my.table mt, other.table ot)…
Enfin, ajouts à pg_backend_memory_contexts avec path (pour récupérer parent/enfant) et type pour distinguer les contextes AllocSet, Generation, Slab et Bump… Et au fait, que sont Slab et Bump ? Pas documentés ; il faut lire les en-têtes des fichiers C ici. Ils existent pour optimiser l’allocation, la réallocation et la réinitialisation mémoire selon les usages attendus. Par exemple, Slab est défini comme un «MemoryContext implementation designed for cases where large numbers of equally-sized objects can be allocated and freed efficiently with minimal memory wastage and fragmentation».
Ah, non, encore une dernière: wal_buffers_full a été ajouté à pg_stat_statements pour permettre un meilleur réglage de wal_buffers.
De meilleures informations apparaissent désormais pour la gestion des conflits en réplication logique grâce à de nouveaux attributs dans pg_stat_subscription_stats. En référence, cet extrait du commit liste les attributs introduits:
confl_insert_exists: nombre de fois où une insertion de ligne a violé une contrainte unique NOT DEFERRABLE.confl_update_origin_differs: nombre de fois où une mise à jour a été faite sur une ligne déjà modifiée par une autre origine.confl_update_exists: nombre de fois où la valeur mise à jour d’une ligne viole une contrainte unique NOT DEFERRABLE.confl_update_missing: nombre de fois où le tuple à mettre à jour est manquant.confl_delete_origin_differs: nombre de fois où une suppression a été effectuée sur une ligne déjà modifiée par une autre origine.confl_delete_missing: nombre de fois où le tuple à supprimer est manquant.Un nouveau jeu de fonctions permet désormais de gérer les statistiques de relations et d’attributs (relpages, avg_width, etc.). Cela offre la possibilité d’exporter, importer et ajuster les stats à volonté, afin de répliquer le comportement du planificateur hors production, de maintenir des stats corrigées, et plus encore.
L’une des évolutions les plus enthousiasmantes est ce que PostgreSQL 18 ouvre aux auteurs d’extensions.
Cette petite ligne au bas de la section E.1.3.9 Modules est celle qui nous intéresse :
Allow extensions to use the server’s cumulative statistics API (Michael Paquier)
Jusqu’ici, la manipulation des statistiques était réservée à l’interne ; désormais, une API officielle et structurée est disponible pour construire (ou envelopper) autour.
Le message de commit est bien rédigé et couvre l’essentiel des nouveautés. Un sous-ensemble des options est détaillé dans la documentation. Cependant, il faut encore plonger dans le code source pour en savoir plus ; en particulier, il vaut la peine de regarder l’extension injection points (fournie avec PostgreSQL) qui utilise cette nouvelle API.
Pour aller plus loin sur la manière dont une extension peut exploiter ces nouvelles capacités, vous pourrez bientôt découvrir PACS (PostgreSQL Advanced Cumulative Statistics) sur Codeberg : mon projet qui propose une bibliothèque de wrappers et des utilitaires autour des nouvelles APIs de statistiques de PostgreSQL 18.
En attendant, la présentation que j’ai donnée à FOSDEM 2025 explore ce sujet plus en détail.
]]>