Le blog Dalibo

La double vie de default_statistics_target

Fri, 10 Jul 2026 00:00:00 -0500

Mont de Marsan, le 10 juillet 2026

Version améliorée et enrichie de l’article initialement publié le 25 juillet 2025.

Dans un précédent article, je vous illustrais à quel point la justesse des statistiques sur les données était critique pour la performance de vos requêtes. Intéressons-nous aujourd’hui au paramètre default_statistics_target et regardons comment il peut nous aider à améliorer les performances de nos requêtes grâce à des statistiques plus précises.

Le principe

Pour obtenir les meilleurs plans d’exécution possibles, PostgreSQL a besoin d’estimer, à chaque étape d’une requête, le nombre de lignes qui seront manipulées.

PostgreSQL a aussi besoin d’estimer la taille moyenne de chaque colonne, par exemple pour déterminer si un tri pourra se faire entièrement en mémoire.

L’échantillonnage

Pour ce faire, nul besoin de mesurer chacune des lignes de chacune des tables. Un échantillon assez grand pris aléatoirement est suffisamment représentatif de l’ensemble. PostgreSQL se base sur cette publication de Surajit Chaudhuri, Rajeev Motwani et Vivek Narasayya “Random sampling for histogram construction: how much is enough?” de 1998 pour déterminer combien de lignes suffisent à construire cet échantillon.

Les développeurs se sont appuyés sur cette étude pour retenir un échantillon de 300 × k lignes, où k est la « cible statistique » de chaque colonne, définie globalement par le paramètre default_statistics_target. Le facteur 300 est codé en dur dans le code source de analyze.c :

std_typanalyze(VacAttrStats *stats)
{
…
  stats->minrows = 300 * stats->attstattarget;
…
}

On comprend que la taille de l’échantillon est donc de 300 fois la valeur de la cible statistique. PostgreSQL utilise donc par défaut un échantillon de 30 000 lignes pour calculer ses statistiques :

postgres=# SHOW default_statistics_target; -- nous avons bien la valeur par défaut
 default_statistics_target 
---------------------------
 100
(1 ligne)
postgres=# ANALYZE VERBOSE matable; -- confirmation de la taille de l'échantillon 
INFO:  analyzing "public.matable"   -- "30000 rows in sample" ci-dessous
INFO:  "matable": scanned 7280 of 7280 pages, containing 990000 live rows and 0 dead rows; 30000 rows in sample, 990000 estimated total rows
ANALYZE
Temps : 376,310 ms

La résolution

Pour chaque colonne, PostgreSQL calcule un certain nombre de statistiques. Elles peuvent être consultées dans la vue pg_stats. Deux d’entre elles, la liste des most common values (MCV) et l’histogramme des valeurs sont particulièrement importantes.

Par exemple, une liste MCV pour une colonne prix d’une table produit pourrait avoir cette forme :

postgres=# SELECT most_common_vals, most_common_freqs 
FROM pg_stats 
WHERE attname='prix' \gx
-[ RECORD 1 ]-----+----------------------------------
most_common_vals  | {4.99,9.99,19.99,29.99,49.99}
most_common_freqs | {0.3,0.1,0.05,0.047,0.03}

Ces cinq prix sont les plus fréquents dans la colonne prix. 30 % des valeurs sont égales à 4,99 et 3 % égales à 49,99.

Pour illustrer la notion d’histogramme, on peut considérer une colonne poids d’une table produit :

postgres=# SELECT histogram_bounds FROM pg_stats WHERE attname='poids' \gx
-[ RECORD 1 ]----+---------------------------
histogram_bounds | {0,30,200,600,1000,10000}

Avec ces 6 bornes, notre histogramme dispose de 5 intervalles. L’écart entre les bornes est ajusté afin que chaque intervalle corresponde sensiblement au même nombre de lignes. Il y a donc environ autant de produits dont le poids est compris entre 0 et 30 g que de produits compris entre 1 et 10 kg.

Mais quelle est la bonne quantité de valeurs fréquentes à retenir pour la liste MCV ? Et combien d’intervalles doit comporter notre histogramme calculé pour les valeurs scalaires ? En regardant dans les fonctions compute_distinct_stats() et compute_scalar_stats(), nous observons ces initialisations :

/* dans compute_distinct_stats() */
	int		num_mcv = stats->attstattarget;

/* dans compute_scalar_stats() */
	int		num_mcv = stats->attstattarget;
	int		num_bins = stats->attstattarget;

Nous constatons que c’est de nouveau la cible statistique de la colonne (attstattarget, égale à default_statistics_target par défaut) qui est utilisée. Par défaut, pour chaque colonne de chaque table, la liste MCV comportera donc jusqu’à 100 valeurs, et l’histogramme jusqu’à 100 intervalles.

La cible statistique sert aussi et surtout à indiquer une résolution pour les statistiques, suffisamment élevée pour qu’elles soient précises et utiles, sans trop l’être pour ne pas pénaliser le temps de planification des requêtes.

Un paramètre, deux fonctions

Nous voyons donc que la cible statistique a deux fonctions distinctes dans la collecte des statistiques par ANALYZE, une pour la taille de l’échantillon, une autre pour la résolution de certaines statistiques, listes MCV et histogrammes.

L’étude citée nous a montré qu’augmenter la taille de l’échantillon n’apporte que peu d’information supplémentaire à partir d’un certain seuil. En revanche, la résolution des statistiques peut parfois être insuffisante, surtout pour l’histogramme, quand on a des valeurs avec une distribution peu régulière, voire erratique.

Grâce à un histogramme de meilleure résolution, l’optimiseur pourra se rendre compte que certains filtres sont plus sélectifs et ajuster le plan d’exécution en conséquence.

Exemple

Considérons la table mesure suivante :

CREATE TABLE mesure (
  id     SERIAL PRIMARY KEY,
  valeur_a  NUMERIC,
  valeur_b  NUMERIC
);
CREATE INDEX idx_valeura ON mesure(valeur_a);
CREATE INDEX idx_valeurb ON mesure(valeur_b);

puis insérons quelques données :

-- un million de mesures : 80 % concentrées autour des dizaines
-- (bandes continues [0,1), [10,11), … [990,991)),
-- 20 % de fond uniforme entre 0 et 1000
INSERT INTO mesure (valeur_a, valeur_b)
SELECT v, v
FROM (
  SELECT CASE WHEN random() < 0.8
              THEN floor(random()*100)*10 + random()
              ELSE random()*1000
         END AS v
  FROM generate_series(1, 1000000)
) t;

Ici, les valeurs sont concentrées autour des dizaines, et plus clairsemées entre les bandes :

postgres=# SELECT count(*) FROM mesure WHERE floor(valeur_a)%10 = 0;
 count  
--------
 819812
(1 ligne)

postgres=# SELECT count(*) FROM mesure WHERE floor(valeur_a)%10 <> 0;
 count  
--------
 180188
(1 ligne)

Nous définissons une cible statistique de 100 pour la colonne valeur_a et de 1000 pour valeur_b. Ceci nous permettra de voir l’impact de la résolution de l’histogramme entre 100 et 1000 intervalles.

ALTER TABLE mesure ALTER COLUMN valeur_a SET STATISTICS 100;
ALTER TABLE mesure ALTER COLUMN valeur_b SET STATISTICS 1000;

À noter que la taille d’échantillon sera de 300 000 lignes dans les deux cas :

postgres=# ANALYZE VERBOSE mesure;
INFO:  analyzing "public.mesure"
INFO:  "mesure": scanned 7353 of 7353 pages, containing 1000000 live rows and 0 dead rows; 300000 rows in sample, 1000000 estimated total rows
ANALYZE

Nous pouvons vérifier la taille des histogrammes :

postgres=# SELECT array_length(histogram_bounds,1) FROM pg_stats WHERE tablename='mesure' AND attname='valeur_a';
SELECT array_length(histogram_bounds,1) FROM pg_stats WHERE tablename='mesure' AND attname='valeur_b';
 array_length 
--------------
          101
(1 ligne)

 array_length 
--------------
         1001
(1 ligne)

Le premier comporte bien 100 intervalles (101 bornes), le second 1000 (1001 bornes), soit la résolution maximale de chaque cible.

Les illustrations suivantes montrent ce que le planificateur estime de la répartition des données pour chaque colonne grâce aux histogrammes. Nous remarquons à quel point l’histogramme sur valeur_b est plus proche de la répartition réelle, rappelée en filigrane.

Cherchons maintenant, dans la zone clairsemée entre deux bandes (en orange ci-dessus), les 100 premières lignes dans l’ordre de la clé primaire (une pagination classique) :

EXPLAIN ANALYZE SELECT * FROM mesure
WHERE valeur_a BETWEEN 504 AND 507 ORDER BY id LIMIT 100;
EXPLAIN ANALYZE SELECT * FROM mesure
WHERE valeur_b BETWEEN 504 AND 507 ORDER BY id LIMIT 100;

                               QUERY PLAN
----------------------------------------------------------------------------------
 Limit  (cost=0.42..1277.87 rows=100 width=26)
        (actual time=0.043..15.608 rows=100 loops=1)
   ->  Index Scan using mesure_pkey on mesure
             (cost=0.42..38336.43 rows=3001 width=26)
             (actual time=0.043..15.603 rows=100 loops=1)
         Filter: ((valeur_a >= '504'::numeric) AND (valeur_a <= '507'::numeric))
         Rows Removed by Filter: 176253
 Planning Time: 0.018 ms
 Execution Time: 15.615 ms
(6 lignes)

                               QUERY PLAN
----------------------------------------------------------------------------------
 Limit  (cost=2015.41..2015.66 rows=100 width=26)
        (actual time=0.488..0.493 rows=100 loops=1)
   ->  Sort  (cost=2015.41..2017.04 rows=655 width=26)
             (actual time=0.488..0.492 rows=100 loops=1)
         Sort Key: id
         Sort Method: top-N heapsort  Memory: 32kB
         ->  Bitmap Heap Scan on mesure  (cost=19.14..1990.37 rows=655 width=26)
                                         (actual time=0.098..0.455 rows=615 loops=1)
               Recheck Cond: ((valeur_b >= '504'::numeric) AND (valeur_b <= '507'::numeric))
               Heap Blocks: exact=584
               ->  Bitmap Index Scan on idx_valeurb  (cost=0.00..18.98 rows=655 width=0)
                                                     (actual time=0.053..0.053 rows=615 loops=1)
                     Index Cond: ((valeur_b >= '504'::numeric) AND (valeur_b <= '507'::numeric))
 Planning Time: 0.095 ms
 Execution Time: 0.502 ms
(11 lignes)

Les deux colonnes contiennent les mêmes données : l’intervalle renferme en réalité 615 lignes (visibles dans le second plan). L’histogramme à haute résolution de valeur_b fournit une estimation de 655, très proche du réel, là où l’histogramme à basse résolution de valeur_a sur-estime à 3001. Certains intervalles de l’histogramme à basse résolution couvrent à la fois des bandes denses et des zones clairsemées. Le planificateur suppose que les lignes sont uniformément réparties sur la largeur de l’intervalle, ce qui n’est pas le cas et le conduit à choisir un plan sous-optimal.

Pour produire un résultat trié par id, le planificateur hésite donc entre deux stratégies : parcourir la table dans l’ordre de la clé primaire en filtrant au passage, quitte à s’arrêter dès la centième ligne trouvée, ou bien récupérer toutes les lignes de l’intervalle via l’index sur la valeur, puis les trier. Le coût de la première stratégie dépend directement de l’estimation : plus l’intervalle semble peuplé, plus le planificateur pense s’arrêter tôt. Avec une estimation à 3001 lignes, il espère trouver ses 100 lignes après avoir parcouru et filtré une faible fraction de l’index sur clé primaire. Inversement, le bitmap index scan suivi d’un tri lui paraît plus coûteux qu’il ne l’est en réalité, car il estime plus de lecture hors cache. Sur valeur_b, avec une meilleure information, il choisira le meilleur plan.

Le premier plan balaye et rejette plus de 176 000 lignes avant de réunir ses 100 lignes : 15,6 ms, contre 0,5 ms pour le second, une trentaine de fois plus rapide (hors cache, l’écart se resserre autour d’un facteur 2, les deux plans ayant alors un coût I/O non négligeable). Même requête, mêmes données, même taille d’échantillon : seule la résolution de l’histogramme diffère.

À retenir

Augmenter la cible statistique permet d’obtenir des statistiques de meilleure qualité, et donc de meilleures performances, au prix d’un ANALYZE/autoanalyze plus coûteux et d’un temps de planification légèrement plus élevé. Il est donc généralement préférable d’augmenter cette cible colonne par colonne, plutôt que globalement avec default_statistics_target.

Pour aller plus loin, je vous invite à revoir la conférence Voyage au centre des statistiques de Louise Leinweber à PGDay FR 2025. Nos formations DEVPG et PERF1 incluent aussi depuis cette année un nouveau module dédié à la compréhension des statistiques utilisées par le planificateur de PostgreSQL.

ldap2pg 6.6 avec GSSAPI

Tue, 07 Jul 2026 00:00:00 -0500

Paris, le 7 juillet 2026

Dalibo vous annonce la disponibilité de ldap2pg 6.6. Cette version apporte l’authentification GSSAPI/Kerberos avec l’annuaire de synchronisation, le support de PostgreSQL 19 beta et quelques correctifs. Suivez la documentation pour installer cette nouvelle version.

Depuis 2017, ldap2pg propose la meilleure solution de synchronisation automatique de rôles et de privilèges pour PostgreSQL. Configurez l’authentification LDAP dans le fichier pg_hba.conf puis utilisez ldap2pg pour créer et configurer les rôles depuis votre annuaire d’entreprise.

GSSAPI/Kerberos

ldap2pg implémente désormais l’authentification GSSAPI/Kerberos pour une configuration sans secret pour l’accès à l’annuaire de synchronisation. L’authentification GSSAPI est un nouveau mécanisme SASL disponible à côté de DIGEST-MD5. Ce mécanisme se configure comme ldaputils avec une subtile différence: le chiffrement GSSAPI est automatiquement désactivé si la connexion est déjà chiffrée avec TLS.

Divers correctifs

Certaines erreurs de configuration ou de synchronisation sont corrigées. Le chargement de configuration historique de ldap2pg 5.9 déclenchera des erreurs pour prévenir des configurations incohérentes. Une erreur de déduplication entraînait la double création de rôles absents, c’est désormais corrigé. Cette version 6.6 apporte donc plus de stabilité et de fiabilité à l’administration.

Autres changements

En avant première, ldap2pg 6.6 est testé sur PostgreSQL 19 beta, sans souci. Enfin, l’image Docker est à nouveau disponible.

Retrouvez la documentation en anglais, des procédures et le support communautaire à ces adresses :

Documentation des changements
Documentation en ligne : http://ldap2pg.rtfd.io/en/latest/
Le projet sur GitHub : https://github.com/dalibo/ldap2pg

Étienne BERSAC et Pierre-Louis GONON développent ldap2pg, un projet du Dalibo Labs. Pour toutes questions techniques, l’équipe recommande d’utiliser la page de ldap2pg sur GitHub.

ldap2pg 6.6 with GSSAPI

Tue, 07 Jul 2026 00:00:00 -0500

Paris, July 7, 2026

Dalibo is pleased to announce the release of ldap2pg 6.6. This version brings GSSAPI/Kerberos authentication with the synchronization directory, support for PostgreSQL 19 beta, and a few bug fixes. Follow the installation documentation to install this new version.

Since 2017, ldap2pg has offered the best solution for automatically synchronizing roles and privileges for PostgreSQL. Configure LDAP authentication in the pg_hba.conf file, then use ldap2pg to create and configure roles from your corporate directory.

GSSAPI/Kerberos

ldap2pg now implements GSSAPI/Kerberos authentication for a secretless configuration when accessing the synchronization directory. GSSAPI authentication is a new SASL mechanism available alongside DIGEST-MD5. This mechanism is configured like ldaputils, with one subtle difference: GSSAPI encryption is automatically disabled if the connection is already encrypted with TLS.

Various Fixes

Some configuration and synchronization errors have been fixed. Loading legacy ldap2pg 5.9 configuration will now trigger errors to prevent inconsistent configurations. A deduplication bug caused missing roles to be created twice; this is now fixed. Version 6.6 therefore brings greater stability and reliability to administration.

Other Changes

As a sneak peek, ldap2pg 6.6 has been tested against PostgreSQL 19 beta without any issues. Finally, the Docker image is available again.

Find the English documentation, guides, and community support at these addresses:

Changelog documentation
Online documentation: http://ldap2pg.rtfd.io/en/latest/
The project on GitHub: https://github.com/dalibo/ldap2pg

Étienne BERSAC and Pierre-Louis GONON develop ldap2pg, a Dalibo Labs project. For any technical questions, the team recommends using the ldap2pg page on GitHub.

pgBackRest plugin for CloudNativePG

Thu, 25 Jun 2026 00:00:00 -0500

Lyon, June 25th, 2026

At Dalibo we are actively working on a pgBackRest plugin for PostgreSQL clusters deployed with CloudNativePG. Here is the announcement of the 0.0.3 version that has just been released.

Backup tools

The PostgreSQL ecosystem is full of tools in various areas. For physical backups, two tools are primarily used by administrators in addition to pg_basebackup tool: Barman and pgBackRest.

CloudNativePG relies, by default, on Barman to create and restore physical backups and also archive WAL files. More specifically, it is based on barman-cloud suite from the Barman project.

The strength of PostgreSQL lies in the plurality and free choice of tools within its wide ecosystem.

We do love pgBackRest for bare metal or virtualized environments and wanted to see this tool also available for CloudNativePG.

People behind CloudNativePG allow new tools to be easily plugged thanks to the CNPG-I project. And here we are with pgBackRest.

Our plugin

For some time now, we have been developing a plugin based on pgBackRest to manage backups of our clusters. The plugin is, of course, open source and can be found on our GitHub page right here https://github.com/dalibo/cnpg-plugin-pgbackrest.

What we are trying to do is offer an alternative based on a well-known and recognized tool.

Version 0.0.3 of the plugin is now available. Here’s what you can do with it:

WALs archiving (using pgBackRest async feature)
Taking and restoring backup (on S3 solutions or Azure Blob Storage)
Point-in-Time Recovery
Creating secondary based on Log Shipping

As you’ve probably guessed, this is an experimental plugin. We would be very happy to receive feedback from your tests to improve what we already did.

Have a look at the project, the documentation and feel free to test it !

Any questions ? Send us an email!

pgBackRest : une réponse communautaire

Thu, 25 Jun 2026 00:00:00 -0500

Paris, le 25 juin 2026

Le 27 avril dernier, les utilisateurs et contributeurs de PostgreSQL ont été surpris d’apprendre l’interruption du développement et de la maintenance de pgBackRest.

Heureusement, la communauté s’est rapidement mobilisée pour en permettre la continuité, et au-delà, la pérennité.

Rappel : ce qu’est pgBackRest

pgBackRest est un outil de sauvegarde et restauration pour PostgreSQL développé par David Steele sous la licence MIT. Son succès technique est tel qu’il reste l’un des outils les plus recommandés.

David Steele était néanmoins le seul mainteneur du projet à assurer la correction des bugs, la revue des PR et le développement de nouvelles fonctionnalités, rémunéré par Crunchy Data jusqu’à son rachat par Snowflake en juin 2025.

Déclarant n’avoir trouvé aucun autre employeur pour prendre financièrement en charge ce temps de contribution, il annonce la fin de pgBackRest fin avril, avant de proposer que le projet soit repris par d’autres via un fork sous un autre nom, c’est-à-dire une copie du code permettant de continuer son développement indépendamment du projet originel.

Heureusement, plusieurs membres de la communauté se sont rapidement mobilisés auprès de David Steele pour tenter d’organiser la continuité de pgBackRest.

Une réponse communautaire

Depuis mai, la réponse se fait sur 3 niveaux : technique, financier et organisationnel.

Techniquement, une transition est en cours afin de renforcer la maintenance de pgBackRest : un second mainteneur devrait arriver, de sorte que David Steele n’en porterait plus seul la responsabilité.

Financièrement, le projet bénéficiera d’un soutien structuré autour d’une coalition de sponsors soucieux de l’avenir des projets open source dont dépend une partie de leurs services.

Dès aujourd’hui, Dalibo fait partie de cette coalition.

Sur le plan de la gouvernance, l’option de recourir à une fondation est actuellement à l’étude, nous en saurons probablement plus dans les semaines ou mois qui viennent.

Cette initiative collective est une très bonne nouvelle pour tout l’écosystème PostgreSQL, pour les fournisseurs de services comme pour les utilisateurs de pgBackRest. Elle offre à l’outil la stabilité dont il a besoin à long terme.

Dalibo, au-delà du soutien financier

Rappelons quelques actions concrètes qui témoignent de l’engagement communautaire de notre entreprise depuis sa création en 2005 :

contributions au code de projets externes avec du temps dédié pour nos équipes ;
publication du code de toutes nos productions sous licences libres (Cf. notre Dalibo Labs) ;
documentation, manuels et supports de formation diffusés sous licence CC‑BY‑NC‑SA ;
présentations des nouveautés logicielles, démos et retours d’expérience partagés publiquement, y compris lors de notre propre événement annuel PGSession ;
sponsorat régulier d’événements communautaires, Dalibo est d’ailleurs l’un des Major Sponsors de PostgreSQL.

Le logiciel libre fait partie de notre ADN, à travers nos produits comme à travers notre politique de sponsorat, nos pratiques de travail et notre comportement commercial.

C’est une conviction forte que nous portons fièrement depuis plus de 20 ans, au sein d’une communauté dynamique.

L’équipe Dalibo

PGSession 19 : appel à conférences

Tue, 23 Jun 2026 00:00:00 -0500

Saint-Étienne, le 23 juin 2026

La PGSession 19, c’est pas pour tout de suite ! Mais bien que la journée Conférences aura lieu le 13 janvier 2027, nous lançons dès aujourd’hui notre appel à conférences.

La PGSession 19

Comme annoncé la semaine dernière, la PGSession 19 se déroulera sur deux journées :

Journée Ateliers : mardi 12 janvier 2027, à l’Espace Batignolles,
Journée Conférences : mercredi 13 janvier 2027, au Pan Piper.

Les présentations ainsi que les échanges avec le public seront retransmis en direct sur pgsessions.com.

L’appel à conférences

Merci de bien vouloir nous envoyer vos propositions d’intervention avant Jeudi 29 octobre 2026 à contact@pgsessions.com en nous communiquant les éléments suivants :

Nom, Prénom
Compte personnel LinkedIn, X et/ou Mastodon
Employeur, fonction
Biographie et éventuelles contributions à la communauté PostgreSQL
Titre de votre conférence
Résumé

Chaque présentation doit durer 30 minutes. Elle sera suivie d’environ 10 minutes d’échange avec le public.

Les thématiques (liste non exhaustive) :

Nouveautés d’un logiciel satellite
Industrialisation
Migration vers PostgreSQL
Performances
Protection des données

Sauvegarde et restauration
Haute disponibilité
Modélisation et développement
Communauté PostgreSQL et contributions
Etc.

Les interventions peuvent prendre plusieurs formes : retour d’expérience, témoignage utilisateur, preuve de concept, tutoriel, étude comparative, etc.

Comme dit plus haut, cette journée sera visible en direct sur pgsessions.com, puis diffusée sur la chaîne Youtube de Dalibo pendant 10 ans. En nous proposant une conférence, vous acceptez sa captation audio/vidéo et vous nous autorisez à utiliser votre image en renonçant à tout droit de compensation pour cela.

À propos de la PGSession : Depuis 2008, la PGSession est un événement annuel organisé par Dalibo. Dans une ambiance conviviale, elle vous permet de découvrir des projets et de rencontrer le staff technique et commercial de Dalibo, ainsi que d’autres membres de la communauté PostgreSQL. À partir de 2018 où elle a célébré ses 10 ans, la PGSession se déploie sur deux journées : une première réservée à des ateliers, et une seconde dédiée aux conférences.

PGSession 19 : rendez-vous les 12 et 13 janvier 2027 à Paris

Thu, 11 Jun 2026 00:00:00 -0500

Saint-Étienne, le 11 juin 2026

À vos agendas ! La prochaine PGSession aura lieu les 12 et 13 janvier 2027 à Paris. L’appel à conférences sera prochainement lancé, tandis que les inscriptions débuteront en octobre.

Rappel : ce qu’est la PGSession

D’inspiration communautaire, l’événement annuel de Dalibo se déroule sur deux journées consécutives : les Ateliers et les Conférences. Vous êtes libre de participer à l’une, à l’autre ou aux deux.

Lors de la PGSession, les acteurs de l’écosystème PostgreSQL francophone peuvent partager et enrichir leurs connaissances, tout en rencontrant des membres de la communauté dans une ambiance conviviale.

Nos DBA consultants et nos développeurs sont au rendez-vous pour mettre en avant leurs travaux. Vous pouvez également échanger avec notre équipe commerciale sur vos besoins et nos services, ainsi qu’avec d’autres membres du personnel mobilisés pour vous accueillir.

Mardi 12 janvier : les Ateliers

En vous inscrivant à partir d’octobre prochain, vous pourrez choisir deux ateliers de trois heures chacun, parmi les quatre proposés.

Tous seront animés en binôme par nos DBA et et nos développeurs.

Vous approfondirez non seulement vos connaissances sur des thématiques telles que la migration, l’anonymisation ou les performances, mais vous découvrirez aussi certains projets de développement internes à Dalibo.

Quel que soit le sujet, vous pourrez vous exercer lors des travaux pratiques.

Mercredi 13 janvier : les Conférences

Si cette seconde journée commencera par la présentation des nouveautés de la dernière version majeure de PostgreSQL, elle abordera ensuite le SGBD sous les angles du développement, de l’administration, et des projets au sein des organisations.

Au menu, des retours d’expériences, des témoignages utilisateurs, des démos, des études comparatives, etc.

L’appel à conférences sera lancé le 23 juin, tandis que le programme sera publié fin octobre.

Pour le public à distance, les conférences seront captées et retransmises en direct sur le site des pgsessions, où un tchat éphémère vous permettra de poser des questions.

Comment vous informer

Pour ne manquer aucune information sur l’événement, retrouvez-nous sur nos réseaux sociaux avec le mot-clé #pgsession19 :

Vous pourrez également demander à recevoir notre newsletter PGSessions en nous écrivant à contact@pgsessions.com.

En attendant, les conférences passées et leurs supports de présentation sont toujours en libre accès sur le site des PGSessions ou sur notre chaîne YouTube !

L’équipe PGSession 19

Plongez dans le monde de CloudNativePG #12 - Mise à jour dynamique de pg_hba.conf

Thu, 28 May 2026 00:00:00 -0500

Lyon, le 28 mai 2026

CloudNativePG ou comment embarquer un éléphant sur un porte-conteneurs !

La configuration d’une instance PostgreSQL, où qu’elle soit déployée, nécessite d’être faite. La configuration des règles d’accès dans pg_hba.conf est essentielle. Regardons une nouveauté de la version 1.29 de l’opérateur qui permet de reconfigurer dynamiquement ce fichier.

Rappel sur pg_hba.conf

L’authentification à une instance est paramétrée au moyen de ce fichier. Lorsque le serveur PostgreSQL reçoit une demande de connexion, il connaît le type de connexion utilisé par le client (socket Unix, connexion TCP SSL, connexion TCP simple, etc.). Il connaît aussi l’adresse IP du client (dans le cas d’une connexion via une socket TCP), le nom de la base et celui de l’utilisateur. En fonction des règles présentes et de la méthode d’authentification indiquée, le client est autorisé, ou non, à se connecter.

Une instance déployée avec CloudNativePG voit son fichier pg_hba.conf être pré-configuré. Il est possible de trouver les règles actuellement définies avec la requête SQL suivante :

select type, database, user_name, address, netmask, auth_method from pg_hba_file_rules ;

  type   |   database    |        user_name        | address | netmask |  auth_method  
---------+---------------+-------------------------+---------+---------+---------------
 local   | {all}         | {cnpg_metrics_exporter} |         |         | peer
 local   | {all}         | {all}                   |         |         | peer
 hostssl | {postgres}    | {streaming_replica}     | all     |         | cert
 hostssl | {replication} | {streaming_replica}     | all     |         | cert
 hostssl | {all}         | {cnpg_pooler_pgbouncer} | all     |         | cert
 host    | {all}         | {all}                   | all     |         | scram-sha-256

La dernière ligne indique que toutes les demandes de connexion à l’instance faites par n’importe quel utilisateur, sur n’importe quelle base et venant de n’importe quelle source, doit utiliser le mécanisme d’authentification scram-sha-256.

Restriction forte des accès

L’ajout de règles se fait via l’opérateur et doit être écrite dans la définition YAML du Cluster. Prenons le cas de figure où l’on souhaite autoriser uniquement un rôle d’administration (admin) à se connecter à la base postgres à distance. Toutes les autres connexions doivent être rejetées (reject). Cela donnerait quelque chose comme :

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgresql-prod
spec:
  instances: 1
  storage:
    size: 1Gi
  postgresql:
    pg_hba:
      - host postgres admin all scram-sha-256
      - host all all all reject

Pour des raisons de sécurité, il est préférable de restreindre les connexions provenant de sources bien identifiées. Ainsi le mot clé all dans cette ligne

      - host postgres admin all scram-sha-256

devrait être changé par 10.244.0.10/32, la seule adresse IP source autorisée. Une restriction forte est donc appliquée… mais qu’en est-il si l’adresse IP autorisée venait à changer une fois ? la modification ne serait pas trop lourde à effectuer. Deux fois ? On prendra notre mal en patience et on le ferait. Mais 100 fois ? 1000 fois ? Cela deviendrait intenable. Ceci est d’autant plus vrai que, dans un contexte Kubernetes, la volatilité des Pods, et donc de leur adresse IP, est grande et même inhérente à sa conception. Il faut donc avoir un outil qui permettrait de tenir à jour le fichier pg_hba.conf de notre Cluster.

Résolution dynamique d’adresse

La version 1.29 de l’opérateur apporte cette solution en se reposant sur le mécanisme de labels de Kubernetes. L’opérateur est capable de reconfigurer le pg_hba.conf dynamiquement avec l’adresse IP des Pods qui ont un label spécifique. Prenons l’exemple d’un Pod pgAdmin déployé avec une ressource Deployment pour laquelle le label app=pgadmin est renseigné.

Dans la partie spec du Cluster, il est désormais possible de renseigner la section podSelectorRefs qui permet d’indiquer une référence aux Pods (podSelectorRefs) ayant un label spécifique (selector.matchLabels).

  podSelectorRefs:
  - name: app-pgadmin
    selector:
      matchLabels:
        app: pgadmin

Aussi, dans la partie pg_hba, le champ correspondant aux adresses IP peut être remplacé par la syntaxe suivante ${podselector:app-pgadmin}.

  postgresql:
    pg_hba:
      - host postgres admin ${podselector:app-pgadmin} scram-sha-256
      - host all all all reject

Désormais, dès lors qu’un Pod avec le label app=pgadmin est créé, CloudNativePG ajustera le fichier pg_hba.conf et rechargera l’instance PostgreSQL pour que la nouvelle adresse IP soit autorisée à se connecter.

Le passage du paramètre spec.replicas à 2 du Deployment pgAdmin est bien “reporté” dans le fichier pg_hba.conf : deux lignes sont présentes avec les adresses IP des Pods pgAdmin.

psql (18.3 (Debian 18.3-1.pgdg13+1))
Type "help" for help.

postgres=# select type, database, user_name, address, netmask, auth_method from pg_hba_file_rules ;
  type   |   database    |        user_name        |   address   |     netmask     |  auth_method  
---------+---------------+-------------------------+-------------+-----------------+---------------
 local   | {all}         | {cnpg_metrics_exporter} |             |                 | peer
 local   | {all}         | {all}                   |             |                 | peer
 hostssl | {postgres}    | {streaming_replica}     | all         |                 | cert
 hostssl | {replication} | {streaming_replica}     | all         |                 | cert
 hostssl | {all}         | {cnpg_pooler_pgbouncer} | all         |                 | cert
 host    | {postgres}    | {admin}                 | 10.244.0.11 | 255.255.255.255 | scram-sha-256
 host    | {postgres}    | {admin}                 | 10.244.0.12 | 255.255.255.255 | scram-sha-256
 host    | {all}         | {all}                   | all         |                 | reject
 host    | {all}         | {all}                   | all         |                 | scram-sha-256
(9 rows)

Conclusion

Maintenir un fichier pg_hba.conf pour autoriser ou interdire les accès est important. Dans un environnement virtualisé ou baremetal, ce fichier n’est généralement mis à jour que très ponctuellement. Dans des environnements Kubernetes où la durée de vie des applications peut être très court, des mécanismes d’automatisation sont nécessaires. C’est le cas de cette nouveauté de la version 1.29 de l’opérateur.

Des questions, des commentaires ? Écrivez-nous !

Sortie de PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23

Fri, 15 May 2026 00:00:00 -0500

Lyon, le 15 mai 2026

Le PostgreSQL Global Development Group a publié le 14 mai une mise à jour pour toutes les versions supportées de PostgreSQL, c’est-à-dire les versions 18.4, 17.10, 16.14, 15.18, 14.23. Cette mise à jour corrige 11 vulnérabilités de sécurité et une soixantaine de bugs.

Pour la liste complète, voir les Notes de version.

Annonce de fin de vie de PostgreSQL 14

PostgreSQL 14 ne recevra plus de mises à jour après le 12 novembre 2026. Si vous utilisez PostgreSQL 14 en production, nous vous conseillons de planifier la migration vers une version plus récente et supportée. Voir la politique de versionnement pour plus de détails.

Vulnérabilités de sécurité

CVE-2026-6472: La commande CREATE TYPE de PostgreSQL ne vérifie pas le droit CREATE de sur tous les schemas

CVSS v3.1 Base Score: 5.4
Versions vulnérables : 14 - 18.
Une faille d’autorisation dans la commande CREATE TYPE de PostgreSQL permet au créateur d’un objet de détourner d’autres requêtes qui utilisent search_path pour rechercher des types définis par l’utilisateur, y compris les types définis par des extensions. En d’autres termes, la victime exécutera des fonctions SQL arbitraires choisies par l’attaquant. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6473: PostgreSQL sous-dimensionne les allocations à cause d’un débordement d’entier

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Le débordement d’entier, dans plusieurs fonctionnalitées de PostgreSQL, autorise une application à forcer le serveur à sous-dimensionner une allocation et à écrire hors limites. Cela entraîne une erreur de segmentation. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6474: La fonction PostgreSQL timeofday() peut divulguer des parties de la mémoire du serveur

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 14 - 18.
Une chaîne de caractères spécifique utilisée dans la fonction timeofday() de PostgreSQL permet à un attaquant d’extraire des portions de la mémoire du serveur, via des fuseaux horaires spécialement conçus. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6475: Les commandes pg_basebackup et pg_rewind de PostgreSQL peuvent écraser des fichiers sans lien avec le choix du superutilisateur

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Le suivi des liens symboliques dans le format brut de pg_basebackup et dans pg_rewind permet à un superutilisateur d’origine de réécrire des fichiers locaux, par exemple /var/lib/postgres/.bashrc, qui détournent le compte du système d’exploitation. Le fait est que le démarrage du serveur après ces commandes implique une confiance implicite envers le superutilisateur d’origine, en raison de fonctionnalités telles que shared_preload_libraries. Par conséquent, l’attaque n’a de conséquences pratiques que si des actions sont faites entre l’exécution de ces commandes et le démarrage du serveur, comme par exemple le déplacement des fichiers vers une autre machine virtuelle ou la création d’un instantané de la machine virtuelle. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6476: La fonction pg_createsubscriber de PostgreSQL permet une injection SQL via le nom de l’abonnement

CVSS v3.1 Base Score: 7.2
Versions vulnérables : 17 - 18.
Une faille d’injection SQL dans la fonction pg_createsubscriber de PostgreSQL permet à un attaquant disposant des droits pg_create_subscription d’exécuter du code SQL arbitraire en tant que superutilisateur. L’attaque se produit lors de la prochaine exécution de pg_createsubscriber. Parmi les versions majeures 17 et 18, les versions mineures antérieures à PostgreSQL 18.4 et 17.10 sont concernées. Les versions antérieures à PostgreSQL 17 ne sont pas concernées.

CVE-2026-6477: Les fonctions lo_* de la bibliothèque libpq de PostgreSQL permettent au superutilisateur du serveur de réécrire la mémoire de la pile du client

CVSS v3.1 Base Score: 8.8
Supported, Vulnerable Versions: 14 - 18.
L’utilisation de la fonction intrinsèquement dangereuse comme PQfn(..., result_is_int=0, ...) dans les fonctions lo_export(), lo_read(), lo_lseek64(), and lo_tell64() de la libpq autorise un superutilisateur de réécrire la pile mémoire d’un client. C’est notamment le cas pour pg_dump et psql qui utilisent lo_read(). Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6478: PostgreSQL divulgue des mots de passe hachés en MD5

CVSS v3.1 Base Score: 6.5
Versions vulnérables : 14 - 18.
Un canal de synchronisation caché dans la comparaison des mots de passe hachés MD5 dans l’authentification PostgreSQL permet à un attaquant de récupérer suffisament d’informations d’utilisateur pour s’authentifier. Cela n’affecte pas les mots de passe hachés en scram-sha-256, qui sont la valeur par défaut dans toutes les versions supportées. Cependant, les bases de données en version 13 existantes peuvent contenir des mots de passe hachés en MD5. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6479: L’initialisation SSL/GSS de PostgreSQL provoque un déni de service, via une récursion non contrôlée.

CVSS v3.1 Base Score: 7.5
Versions vulnérables : 14 - 18.
Une récursion incontrôlée dans la négociation SSL et GSS de PostgreSQL permet à un attaquant capable de se connecter à un socket AF_UNIX de PostgreSQL, d’obtenir un déni de service. Si SSL et GSS sont désactivés, un attaquant peut réaliser la même opération en accédant à un socket TCP de PostgreSQL. Les versions antérieures à PostgreSQL 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6575: La fonction pg_restore_attribute_stats de PostgreSQL accepte des valeurs qui entraînent une lecture au-delà de la fin du tableau de statistiques lors de la planification de la requête.

CVSS v3.1 Base Score: 4.3
Versions vulnérables : 18.
Une vulnérabilité de lecture du tampon dans la fonction pg_restore_attribute_stats() de PostgreSQL accepte des valeurs de tableau de longueur non adéquat, ce qui provoque une lecture au-delà de la fin d’un tableau lors de la planification de la requête. Ceci permet à un responsable de table de déduire des valeurs en mémoire au-delà de cette fin de tableau. Ce problème affecte les versions majeures antérieures à PostgreSQL 18 et 18.4. Les versions antérieures à PostgreSQL 18 ne sont pas concernées.

CVE-2026-6637: Le module PostgreSQL refint permet le dépassement de tampon de pile et l’injection SQL.

CVSS v3.1 Base Score: 8.8
Versions vulnérables : 14 - 18.
Un dépassement de tampon de la pile dans le module refint de PostgreSQL permet à un utilisateur de base de données non privilégié d’exécuter du code arbitraire en tant qu’utilisateur du système d’exploitation exécutant la base de données. Une autre attaque est possible si l’application déclare une colonne utilisateur comme clé primaire en cascade. Une injection SQL est possible en mettant à jour la valeur de la clé primaire. Le code SQL est exécuté en tant qu’utilisateur de la base de données effectuant la mise à jour de la clé primaire. Les versions de PostgreSQL antérieures à 18.4, 17.10, 16.14, 15.18 et 14.23 sont concernées.

CVE-2026-6638: PostgreSQL REFRESH PUBLICATION autorise l’injection SQL via le nom de la table.

CVSS v3.1 Base Score: 3.7
Versions vulnérables : 16 - 18.
Une injection SQL dans la réplication logique de PostgreSQL (ALTER SUBSCRIPTION ... REFRESH PUBLICATION) permet au créateur d’une table abonnée d’exécuter du code SQL arbitraire avec les identifiants de publication de l’abonnement. L’attaque prend effet lors du prochain appel à REFRESH PUBLICATION. Les versions majeures 16, 17 et 18, ainsi que les versions mineures antérieures à PostgreSQL 18.4, 17.10 et 16.14, sont concernées. Les versions antérieures à PostgreSQL 16 ne sont pas affectées.

Correctifs et améliorations

Correction d’un problème pouvant entraîner des résultats erronés lors de l’utilisation d’une collation non déterministe sur un index unique.
Auparavant, une clé étrangère définie comme DEFERRABLE INITIALLY DEFERRED se comportait comme si elle était NOT DEFERRABLE après avoir été mise en état NOT ENFORCED, puis revenue à l’état ENFORCED. C’est maintenant corrigé. Si vous avez une clé étrangère présentant ce problème, vous pouvez le résoudre après avoir installé cette mise à jour en la positionnant comme NOT ENFORCED puis ENFORCED.
Amélioration du planificateur lors du nettoyage de partitions.
Correctif sur les self-join pour mieux gérer les clauses qui ne portent que sur des colonnes de type booléen.
Plusieurs corrections concernent les colonnes générées virtuellement, notamment pour garantir que INSERT ... ON CONFLICT fonctionne lorsque EXCLUDED fait référence à une colonne générée virtuellement.
Un échec de sérialisation est signalé lorsque MERGE rencontre une ligne mis à jour simultanément avec les modes d’isolation « repeatable » ou « serializable ».
Correction de CREATE TABLE ... LIKE ... INCLUDING STATISTICS pour les cas où la table source comportait une ou plusieurs colonnes supprimées.
Correction de WITHOUT OVERLAPS pour autoriser l’utilisation de domaines.
Interdiction de faire d’un type composite un membre de lui-même via un multirange.
Correction de résultats parfois incorrects lorsque array_agg(anyarray) s’exécute en parallèle.
Le bloat n’est plus conservé lors d’une restauration à partir d’une sauvegarde incrémentale.
La promotion d’une instance standby n’est plus bloquée par un processus de synchronisation des slots de réplication logique.
La colonne pid de la vue système pg_aios affiche NULL au lieu de 0 lorsqu’une entrée n’a pas de processus associé.
Correction des cas où pg_stat_replication affiche un lag NULL même lorsque la réplication est active.
L’affichage des variables d’alias JOIN utilisées dans GROUP BY est maintenant correct.
Si le processus de démarrage échoue, les autres processus enfants sont correctement arrêtés avant de stopper le postmaster.
Correction d’une race condition qui pouvait entraîner une instance stanby, suivant une instance primaire dans une version mineure antérieure, à entrer dans une boucle infinie de plantage et de redémarrage.
Empêche l’attente infine lors de l’arrêt d’un processus walsender lorsque la réplication logique publie activement des données.
Les modifications apportées aux free space map des tables sont conservées pendant un recovery. Cela pourrait améliorer les performances d’une instance standby après sa promotion.
Correction de divers bugs dans le code de décompression des sauvegardes utilisé dans pg_basebackup et pg_verifybackup.
Garantie que pg_dumpall n’oublie pas de GRANT sur des rôles qui auraient été donnés par un ROLE dont l’OID serait manquant.. Un message d’avertissement est affiché sur la source du dump est PostgreSQL 16 ou une version ultérieure.
Correction de pg_upgrade pour qu’il utilise la bonne version du protocole lors de la connexion à d’anciens serveurs sources.
Correction de la sortie dans pg_overexplain lors de l’utilisation de l’option RANGE_TABLE.
Correction d’un bug dans postgres_fdw causé par le nettoyage prématuré d’une connexion ayant échoué.

Mettre à jour

Toutes les mises à jour de PostgreSQL sont cumulatives. Pour appliquer la mise à jour, comme pour les autres versions mineures, les utilisateurs n’ont pas besoin de sauvegarder et recharger leur base de données, ni d’utiliser pg_upgrade. Vous pouvez simplement arrêter PostgreSQL et mettre à jour ses binaires.

Les utilisateurs ayant sauté une version mineure ou plus peuvent avoir besoin de réaliser d’autres opérations post-mise à jour. Voir les Notes de version pour les détails.

Liens

Manuels Dalibo : leur dernière mise à jour intègre PostgreSQL 18

Fri, 15 May 2026 00:00:00 -0500

Saint-Étienne, le 15 mai 2026

Voici les manuels Dalibo dans leur dernière version, qui intègre les nouveautés de PostgreSQL 18. Toujours en libre accès sous format PDF, ePub, html et slides !

Rappels utiles

Revue des cours, nouveaux TP et quiz, correctifs… La mise à jour des manuels est assurée nos DBA, par ailleurs formateurs et consultants.

Découvrez le sommaire des formations Dalibo, le détail des différents modules et les liens vers les slides ici.

Si vous notez des éléments qui demandent à être clarifiés, précisés, corrigés, vous pouvez nous écrire à formation@dalibo.com.

Les manuels sont publiés sous la licence CC BY-NC-SA qui autorise l’utilisation non commerciale, le partage dans les mêmes conditions et la modification, à condition de créditer Dalibo.

Les manuels

IMPORTANT : leur dernière version intègre les nouveautés de PostgreSQL 18.

Administration

DBA1 - Administration PostgreSQL : PDF, ePub, html
DBA2 - Administration PostgreSQL Avancée : PDF, ePub, html
DBA3 - Sauvegarde et Réplication avec PostgreSQL : PDF, ePub, html
HAPAT - Haute disponibilité avec PostgreSQL : PDF, ePub, html

Développement

DEVPG - Développer avec SQL : PDF, ePub, html

Performances

PERF1 - PostgreSQL Performances : PDF, ePub, html
PERF2 - Indexation et SQL Avancés : PDF, ePub, html

Transition vers PostgreSQL

DBAADM - Administration PostgreSQL pour DBA expérientés : PDF, ePub, html

Le privilège des stagiaires

Ces manuels ne sont pas commercialisés. Cependant, en vous inscrivant à une formation Dalibo, vous recevrez un code pour commander gratuitement l’impression et la livraison à domicile de deux manuels de votre choix.

Nous rappelons d’ailleurs que nos DBA donnent ces formations en intra ou inter-entreprises, en présentiel dans nos locaux parisiens, ou à distance.

En attendant, bonne lecture à vous !

Des questions, des remarques ?

Écrivez-nous à formation@dalibo.com.