Vue imprimable multi-pages de cette section. .

Documentation PgBouncer 1.25.2

PgBouncer - Pooler de connexions léger pour PostgreSQL

1: Fonctionnalités
2: Configuration : pgbouncer.ini
3: Usage : pgbouncer commande
4: Compilation et installation de PgBouncer
5: Source Versions Téléchargement
6: Journal des modifications
7: Communauté
8: Questions fréquemment posées

pgbouncer est un pooler de connexions PostgreSQL. Toute application cliente peut se connecter à pgbouncer comme s’il était un serveur PostgreSQL, et pgbouncer établira une connexion vers le serveur réel, ou réutilisera l’une de ses connexions existantes.

L’objectif de pgbouncer est de réduire l’impact sur les performances lié à l’ouverture de nouvelles connexions vers PostgreSQL.

Afin de ne pas compromettre la sémantique transactionnelle pour le pooling de connexions, pgbouncer prend en charge plusieurs types de pooling lors de la rotation des connexions :

Pooling de sessions : Méthode la moins intrusive. Lorsqu’un client se connecte, une connexion serveur lui est attribuée pour toute la durée de sa connexion. Lorsque le client se déconnecte, la connexion serveur est remise dans le pool. Il s’agit de la méthode par défaut.
Pooling de transactions : Une connexion serveur est attribuée à un client uniquement pendant une transaction. Lorsque PgBouncer détecte la fin de la transaction, la connexion serveur est remise dans le pool.
Pooling d’instructions : Méthode la plus agressive. La connexion serveur est remise dans le pool immédiatement après la fin d’une requête. Les transactions à plusieurs instructions sont interdites en ce mode.

1 - Fonctionnalités

Fonctionnalités de PgBouncer — modes de pool et compatibilité SQL

Plusieurs niveaux de sévérité lors de la rotation des connexions :
Pooling de sessions : Méthode la moins intrusive. Lorsqu’un client se connecte, une connexion serveur lui est attribuée pour toute la durée de sa connexion. Lorsque le client se déconnecte, la connexion serveur est remise dans le pool. Ce mode prend en charge toutes les fonctionnalités de PostgreSQL.
Pooling de transactions : Une connexion serveur est attribuée à un client uniquement pendant une transaction. Lorsque PgBouncer détecte la fin de la transaction, le serveur est remis dans le pool. Ce mode désactive quelques fonctionnalités basées sur la session de PostgreSQL. Vous ne pouvez l’utiliser que si l’application coopère en ne utilisant pas les fonctionnalités qui causent des incompatibilités. Consultez le tableau ci-dessous pour les fonctionnalités incompatibles.
Pooling d’instructions : Méthode la plus agressive. Il s’agit d’un pooling de transactions avec une particularité : les transactions à plusieurs instructions sont interdites. Cette configuration vise à imposer le mode « autocommit » sur le client, principalement destinée à PL/Proxy.
Faibles besoins en mémoire (2 kB par connexion par défaut). Cela est dû au fait que PgBouncer n’a pas besoin de voir entièrement les paquets à la fois.
Il n’est pas lié à un seul serveur backend. Les bases de données de destination peuvent résider sur des hôtes différents.
Prise en charge de la reconfiguration en temps réel pour la plupart des paramètres.
Prise en charge du redémarrage/mise à jour en direct sans interrompre les connexions clients.

Carte des fonctionnalités SQL pour les modes de mise en pool

Le tableau suivant liste diverses fonctionnalités de PostgreSQL et indique leur compatibilité avec les modes de poolage de PgBouncer. Notez que le poolage transactionnel rompt délibérément les attentes du client concernant le serveur et ne peut être utilisé que si l’application coopère en ne faisant pas usage des fonctionnalités non prises en charge.

Fonctionnalité	Pooling de sessions	Pooling de transactions
Paramètres de démarrage ¹	Oui	Oui
SET/RESET	Oui	Jamais
LISTEN	Oui	Jamais
NOTIFY	Oui	Oui
Curseur WITHOUT HOLD	Oui	Oui
Curseur WITH HOLD	Oui	Jamais
Plans préparés au niveau du protocole	Oui	Oui ²
PREPARE / DEALLOCATE	Oui	Jamais
Suppression des tables temporaires ON COMMIT	Oui	Oui
Conservation/Suppression des lignes dans les tables temporaires	Oui	Jamais
Réinitialisation des plans mis en cache	Oui	Oui
Instruction LOAD	Oui	Jamais
Verrous d’advisory au niveau de la session	Oui	Jamais

Les paramètres de démarrage sont client_encoding, DateStyle, IntervalStyle, Timezone, standard_conforming_strings et application_name. PgBouncer détecte leurs modifications et peut ainsi garantir leur cohérence pour le client. Pour prendre en charge d’autres paramètres, consultez track_extra_parameters et ignore_startup_parameters . ↩︎
Vous devez définir max_prepared_statements sur une valeur non nulle pour activer cette prise en charge. ↩︎

2 - Configuration : pgbouncer.ini

Fichier de configuration PgBouncer (pgbouncer.ini) – Référence

Description

Le fichier de configuration est au format « ini ». Les noms de section sont entre [ et ]. Les lignes commençant par ; ou # sont traitées comme des commentaires et ignorées. Les caractères ; et # ne sont pas reconnus comme spéciaux lorsqu’ils apparaissent ultérieurement dans la ligne.

Paramètres génériques

fichier_journal

Spécifie le fichier de journalisation. En mode démon (-d), il faut définir soit ce paramètre, soit syslog.

Le fichier journal reste ouvert, de sorte que, après rotation, il faut exécuter kill -HUP ou depuis la console RELOAD;. Sur Windows, le service doit être arrêté puis redémarré.

Notez que la configuration de logfile ne désactive pas en elle-même la journalisation vers stderr. Utilisez l’option en ligne de commande -q ou -d à cette fin.

Par défaut : non défini

fichier_pid

Spécifie le fichier PID. Sans pidfile défini, la démonisation (-d) n’est pas autorisée.

Par défaut : non défini

écoute_adresse

Spécifie une liste (séparée par des virgules) d’adresses sur lesquelles écouter les connexions TCP. Vous pouvez également utiliser *, ce qui signifie « écouter sur toutes les adresses ». Si ce paramètre n’est pas défini, seules les connexions via socket Unix sont acceptées.

Les adresses peuvent être spécifiées sous forme numérique (IPv4/IPv6) ou par nom.

Par défaut : non défini

port_ecoute

Port sur lequel écouter. S’applique aux sockets TCP et Unix.

Par défaut : 6432

répertoire_socket_unix

Spécifie l’emplacement des sockets Unix. S’applique à la fois au socket d’écoute et aux connexions vers le serveur. Si la valeur est une chaîne vide, les sockets Unix sont désactivés. Une valeur commençant par @ indique qu’un socket Unix dans l’espace de noms abstrait doit être créé (actuellement pris en charge sous Linux et Windows).

Pour permettre le redémarrage en ligne (-R), une socket Unix doit être configurée et être située dans l’espace de noms du système de fichiers.

Par défaut : /tmp (vide sous Windows)

mode_socket_unix

Mode système de fichiers pour les sockets Unix. Ignoré pour les sockets dans l’espace de noms abstrait. Non pris en charge sous Windows.

Valeur par défaut : 0777

groupe_socket_unix

Nom du groupe à utiliser pour la socket Unix. Ignoré pour les sockets dans l’espace de noms abstrait. Non pris en charge sous Windows.

Par défaut : non défini

utilisateur

Si défini, spécifie l’utilisateur Unix auquel passer après le démarrage. Fonctionne uniquement si PgBouncer est lancé en tant qu’utilisateur root ou s’il est déjà en cours d’exécution en tant qu’utilisateur donné. Non pris en charge sous Windows.

Par défaut : non défini

mode_pool

Spécifie quand une connexion serveur peut être réutilisée par d’autres clients.

session : Le serveur est rendu au pool après la déconnexion du client. Valeur par défaut.
transaction : Le serveur est rendu au pool après la fin de la transaction.
statement : Le serveur est rendu au pool après la fin de la requête. Les transactions étendant sur plusieurs instructions sont interdites en ce mode.

max_client_conn

Nombre maximal de connexions clients autorisées.

Lorsque ce paramètre est augmenté, les limites de descripteurs de fichiers du système d’exploitation doivent également être ajustées. Notez que le nombre de descripteurs de fichiers utilisés potentiellement dépasse max_client_conn. Si chaque utilisateur se connecte sous son propre nom d’utilisateur au serveur, le maximum théorique utilisé est :

max_client_conn + (max pool_size * total databases * total users)

Si un utilisateur de base de données est spécifié dans la chaîne de connexion (tous les utilisateurs se connectent sous le même nom d’utilisateur), le maximum théorique est :

max_client_conn + (max pool_size * total databases)

Le nombre maximum théorique ne devrait jamais être atteint, sauf si quelqu’un conçoit délibérément une charge spécifique à cet effet. Toutefois, cela signifie que vous devez définir le nombre de descripteurs de fichiers à une valeur suffisamment élevée pour garantir une sécurité.

Recherchez ulimit dans la page de manuel de votre shell préféré. Note : ulimit n’est pas applicable dans un environnement Windows.

Valeur par défaut : 100

taille_pool_par_defaut

Le nombre maximal de connexions serveur autorisées par couple utilisateur/base de données. Peut être remplacé par pool_size dans la configuration par base de données et par utilisateur ; il s’agit de la valeur par défaut utilisée si aucun pool_size spécifique n’est défini pour une base de données ou un utilisateur donné.

Valeur par défaut : 20

taille_min_pool

Ajoutez davantage de connexions serveur à la pool si le nombre est inférieur à cette valeur. Améliore le comportement lorsque la charge normale revient soudainement après une période d’inactivité totale. La valeur est effectivement limitée au nombre maximal de connexions dans la pool.

Appliqué uniquement aux pools où au moins l’une des conditions suivantes est vraie :

l’entrée dans la section [database] pour le pool a une valeur définie pour la clé user (appelée utilisateur forcé)
il y a au moins un client connecté au pool

Par défaut : 0 (désactivé)

taille_piscine_reserve

Nombre de connexions supplémentaires autorisées vers un pool (voir reserve_pool_timeout). 0 désactive.

Par défaut : 0 (désactivé)

timeout_reserve_pool

Si un client n’a pas été servi pendant cette durée, utilisez des connexions supplémentaires provenant du pool de réserve. La valeur 0 désactive cette fonctionnalité. [secondes]

Par défaut : 5.0

max_connexions_base_données

N’autorisez pas plus de ce nombre de connexions serveur par base de données (quelle que soit l’utilisateur). Cette limite tient compte de la base de données PgBouncer à laquelle le client est connecté, et non de la base de données PostgreSQL de la connexion sortante.

Cela peut également être défini par base de données dans la section [databases].

Notez qu’en atteignant la limite, la fermeture d’une connexion client vers un pool ne permettra pas immédiatement d’établir une connexion serveur pour un autre pool, car la connexion serveur du premier pool reste ouverte. Une fois que la connexion serveur est fermée (en raison du délai d’inactivité), une nouvelle connexion serveur sera immédiatement établie pour le pool en attente.

Par défaut : 0 (illimité)

max_conn_client_base_données

N’autorisez pas plus de ce nombre de connexions clients à PgBouncer par base de données (quelle que soit l’utilisateur). Cette limite tient compte de la base de données PgBouncer à laquelle le client est connecté, et non de la base de données PostgreSQL de la connexion sortante.

Il doit être défini à une valeur supérieure ou égale à max_db_connections. La différence entre ces deux valeurs peut être interprétée comme le nombre maximal de connexions à une base de données donnée pouvant être en file d’attente en attendant que les connexions actives se terminent.

Cela peut également être défini par base de données dans la section [databases].

Par défaut : 0 (illimité)

max_user_connections

N’autorisez pas plus de ce nombre de connexions serveur par utilisateur (quelle que soit la base de données). Cette limite tient compte de l’utilisateur PgBouncer associé à un pool, qui est soit l’utilisateur spécifié pour la connexion serveur, soit, en l’absence de celui-ci, l’utilisateur avec lequel le client est connecté.

Cela peut également être défini par utilisateur dans la section [users].

Par défaut : 0 (illimité)

max_user_client_connections

N’autorisez pas plus de ce nombre de connexions clients par utilisateur (indépendamment de la base de données). Cette valeur doit être définie à un nombre supérieur à max_user_connections. La différence entre max_user_connections et max_user_client_connections peut être conceptualisée comme la taille maximale de la file d’attente pour l’utilisateur.

Cela peut également être défini par utilisateur dans la section [users].

Par défaut : 0 (illimité)

server_round_robin

Par défaut, PgBouncer réutilise les connexions serveur selon un mode LIFO (dernier entré, premier sorti), ce qui fait que peu de connexions supportent la charge la plus importante. Ce comportement offre les meilleures performances si vous disposez d’un seul serveur servant une base de données. Toutefois, si un système de répartition de charge (round-robin) est placé derrière une adresse de base de données (TCP, DNS ou liste d’hôtes), il est préférable que PgBouncer utilise également les connexions selon ce mode, afin d’obtenir une répartition uniforme de la charge.

Valeur par défaut : 0

suivi_des_paramètres_supplémentaires

Par défaut, PgBouncer suit les paramètres client_encoding, datestyle, timezone, standard_conforming_strings et application_name par client. Pour autoriser le suivi d’autres paramètres, ceux-ci peuvent être spécifiés ici, afin que PgBouncer sache qu’ils doivent être conservés dans le cache des variables client et restaurés sur le serveur chaque fois que le client devient actif.

Si vous devez spécifier plusieurs valeurs, utilisez une liste séparée par des virgules (par exemple, default_transaction_read_only, IntervalStyle)

Note : La plupart des paramètres ne peuvent pas être suivis de cette manière. Seuls les paramètres que PostgreSQL signale au client peuvent être suivis. PostgreSQL dispose d’une liste officielle des paramètres qu’il signale au client . Les extensions PostgreSQL peuvent toutefois modifier cette liste : elles peuvent ajouter des paramètres qu’elles signalent elles-mêmes, ou commencer à signaler des paramètres existants que PostgreSQL ne signale pas. Citrus 12.0+ en particulier provoque le signal de search_path.

Le protocole Postgres permet de spécifier des paramètres, soit directement comme un paramètre dans le paquet de démarrage, soit à l’intérieur du paquet de démarrage options . Les paramètres spécifiés par l’une ou l’autre de ces méthodes sont pris en charge par track_extra_parameters. Toutefois, il n’est pas possible d’inclure options lui-même dans track_extra_parameters, uniquement les paramètres contenus dans options.

Par défaut : IntervalStyle

ignore_startup_parameters

Par défaut, PgBouncer autorise uniquement les paramètres qu’il peut suivre dans les paquets de démarrage : client_encoding, datestyle, timezone et standard_conforming_strings. Tous les autres paramètres provoquent une erreur. Pour autoriser d’autres paramètres, ils peuvent être spécifiés ici, afin que PgBouncer sache qu’ils sont gérés par l’administrateur et qu’il puisse les ignorer.

Si vous devez spécifier plusieurs valeurs, utilisez une liste séparée par des virgules (par exemple, options,extra_float_digits)

Le protocole Postgres permet de spécifier des paramètres, soit directement comme un paramètre dans le paquet de démarrage, soit à l’intérieur du paquet de démarrage options . Les paramètres spécifiés par l’une ou l’autre de ces méthodes sont pris en charge par ignore_startup_parameters. Il est même possible d’inclure options lui-même dans track_extra_parameters, ce qui entraîne l’ignorance de tout paramètre inconnu contenu dans options.

Par défaut : vide

peer_id

L’identifiant pair utilisé pour identifier ce processus PgBouncer au sein d’un groupe de processus PgBouncer interconnectés. La valeur peer_id doit être unique au sein d’un groupe de processus PgBouncer interconnectés. Si elle est définie à 0, l’interconnexion des processus PgBouncer est désactivée. Pour plus d’informations, consultez la documentation de la section [peers]. La valeur maximale pouvant être utilisée pour peer_id est 16383.

Valeur par défaut : 0

désactiver_pqexec

Désactivez le protocole Simple Query (PQexec). Contrairement au protocole Extended Query, le protocole Simple Query permet d’envoyer plusieurs requêtes dans un même paquet, ce qui expose à certains types d’attaques par injection SQL. Sa désactivation peut améliorer la sécurité. Évidemment, cela signifie que seuls les clients utilisant exclusivement le protocole Extended Query resteront fonctionnels.

Valeur par défaut : 0

application_name_add_host

Ajoutez l’adresse IP du client et le port à la configuration du nom d’application définie au démarrage de la connexion. Cela permet d’identifier la source de requêtes incorrectes, etc. Cette logique s’applique uniquement au démarrage d’une connexion. Si application_name est modifié ultérieurement avec SET, PgBouncer ne le modifie pas à nouveau.

Valeur par défaut : 0

fichier de configuration

Affiche l’emplacement du fichier de configuration actuel. Modifier cette valeur fera que PgBouncer utilisera un autre fichier de configuration pour la prochaine RELOAD / SIGHUP.

Par défaut : fichier fourni en ligne de commande

nom_service

Utilisé lors de l’enregistrement du service win32.

Valeur par défaut : pgbouncer

job_name

Alias pour service_name.

stats_period

Détermine à quelle fréquence les moyennes affichées par diverses commandes SHOW sont mises à jour et à quelle fréquence les statistiques agrégées sont écrites dans le journal (mais voir log_stats). [secondes]

Valeur par défaut : 60

max_préparations_statistiques

Lorsque cette valeur est différente de zéro, PgBouncer suit les commandes liées aux instructions préparées nommées au niveau du protocole envoyées par le client en mode transaction ou pooling d’instructions. PgBouncer garantit que toute instruction préparée par un client est disponible sur la connexion serveur d’arrière-plan. Même lorsque l’instruction a été initialement préparée sur une autre connexion serveur.

PgBouncer examine internement toutes les requêtes envoyées par les clients sous forme de requête préparée, et attribue à chaque chaîne de requête unique un nom interne au format PGBOUNCER_{unique_id}. Si la même chaîne de requête est préparée plusieurs fois (éventuellement par des clients différents), ces requêtes partagent le même nom interne. PgBouncer ne prépare la requête sur le serveur PostgreSQL réel qu’en utilisant le nom interne (et non le nom fourni par le client). PgBouncer suit le nom que le client a attribué à chaque requête préparée. Il réécrit ensuite chaque commande utilisant une requête préparée en remplaçant le nom côté client par le nom interne (par exemple, en remplaçant my_prepared_statement par PGBOUNCER_123) avant de transmettre cette commande au serveur. Plus important encore, si la requête préparée que le client souhaite exécuter n’est pas encore préparée sur le serveur (par exemple, parce qu’un serveur différent est désormais affecté au client que lors de la préparation de la requête), alors PgBouncer prépare la requête de manière transparente avant de l’exécuter.

Note : Le suivi et la réécriture des commandes de requêtes préparées ne fonctionnent pas pour les commandes de requêtes préparées au niveau SQL, aussi PREPARE, EXECUTE et DEALLOCATE sont-ils acheminés directement vers Postgres. L’exception à cette règle concerne les commandes DEALLOCATE ALL et DISCARD ALL, qui fonctionnent comme prévu et effacent les requêtes préparées que PgBouncer a suivies pour le client qui envoie cette commande.

La valeur réelle de ce paramètre contrôle le nombre d’instructions préparées conservées actives dans un cache LRU sur une connexion serveur unique. Lorsque ce paramètre est défini à 0, le support des instructions préparées est désactivé pour le pooling de transactions et le pooling d’instructions. Pour obtenir les meilleurs performances, vous devez veiller à ce que cette valeur soit supérieure au nombre d’instructions préparées couramment utilisées par votre application. Prenez en compte que plus cette valeur est élevée, plus la consommation mémoire de chaque connexion PgBouncer sur votre serveur PostgreSQL sera importante, car davantage d’instructions seront conservées préparées sur ces connexions. Cela augmente également la consommation mémoire de PgBouncer lui-même, car il doit maintenant suivre les chaînes de requêtes.

L’impact sur la mémoire utilisée par PgBouncer n’est toutefois pas important :

Chaque requête unique est stockée une seule fois dans un cache de requêtes global.
Chaque connexion client conserve une mémoire tampon utilisée pour réécrire les paquets. Cette mémoire tampon ne dépasse pas 4 fois la taille de pkt_buf. Ce plafond est généralement non atteint, cela ne se produit que lorsque les requêtes contenues dans vos instructions préparées sont comprises entre 2 et 4 fois la taille de pkt_buf.

Considérez le scénario suivant comme exemple :

Il y a 1000 clients actifs
Les clients préparent 200 requêtes uniques
La taille moyenne d’une requête est de 5kB
La valeur du paramètre pkt_buf est définie par défaut à 4096 (4kB)

Ensuite, PgBouncer a besoin au plus de la quantité suivante de mémoire pour gérer ces requêtes préparées :

200 x 5kB + 1000 x 4 x 4kB = ~17MB of memory.

Le suivi des requêtes préparées entraîne non seulement un coût mémoire, mais aussi une utilisation accrue du CPU, car PgBouncer doit inspecter et réécrire les requêtes. Plusieurs instances de PgBouncer peuvent écouter sur le même port afin d’utiliser plusieurs cœurs pour le traitement ; consultez la documentation de l’option so_reuseport pour plus de détails .

Bien entendu, les requêtes préparées offrent également des bénéfices en termes de performance. Tout comme lors d’une connexion directe à PostgreSQL, en préparant une requête exécutée plusieurs fois, on réduit la quantité totale d’analyse syntaxique et de planification nécessaire. La manière dont PgBouncer suit les requêtes préparées est particulièrement avantageuse pour les performances lorsque plusieurs clients préparent la même requête. Comme les connexions clients réutilisent automatiquement une requête préparée sur une connexion serveur, même si elle a été préparée par un autre client. Par exemple, si vous avez un pool_size de 20 et que 100 clients préparent exactement la même requête, alors la requête n’est préparée (et donc analysée) que 20 fois sur le serveur PostgreSQL.

La réutilisation des requêtes préparées présente un inconvénient. Si les types de retour ou d’argument d’une requête préparée changent entre deux exécutions, PostgreSQL lève actuellement une erreur telle que :

ERROR:  cached plan must not change result type

Vous pouvez éviter ces erreurs en ne faisant pas coexister plusieurs clients utilisant exactement la même chaîne de requête dans une instruction préparée, tout en attendant des types d’arguments ou de résultats différents. L’une des causes les plus fréquentes de ce problème survient lors d’une migration DDL, par exemple lorsqu’une nouvelle colonne est ajoutée ou qu’un type de colonne est modifié sur une table existante. Dans ces cas, vous pouvez exécuter RECONNECT sur la console d’administration de PgBouncer après la migration afin de forcer la re-préparation de la requête et faire disparaître l’erreur.

Valeur par défaut : 200

nombre_d_itérations_scram

Nombre d’itérations de calcul à effectuer lors du hachage d’un mot de passe à l’aide de SCRAM-SHA-256. Un nombre plus élevé d’itérations offre une protection renforcée contre les attaques par force brute sur les mots de passe stockés, mais ralentit l’authentification.

Valeur par défaut : 4096

Paramètres d’authentification

PgBouncer gère son propre mécanisme d’authentification des clients et dispose de sa propre base d’utilisateurs. Ces paramètres contrôlent ce comportement.

type_d’authentification

Comment authentifier les utilisateurs.

cert: Le client doit se connecter via une connexion TLS munie d’un certificat client valide. Le nom d’utilisateur est ensuite extrait du champ CommonName du certificat.
md5: Utiliser la vérification de mot de passe basée sur MD5. Il s’agit de la méthode d’authentification par défaut. auth_file peut contenir à la fois des mots de passe chiffrés en MD5 et des mots de passe en clair. Si md5 est configuré et qu’un utilisateur dispose d’un secret SCRAM, l’authentification SCRAM est utilisée automatiquement à la place.
scram-sha-256: Utiliser la vérification de mot de passe avec SCRAM-SHA-256. auth_file doit contenir des secrets SCRAM ou des mots de passe en clair.
plain: Le mot de passe en clair est transmis sur le réseau. Obsolète.
trust: Aucune authentification n’est effectuée. Le nom d’utilisateur doit toutefois exister dans auth_file.
any: Comme la méthode trust, mais le nom d’utilisateur fourni est ignoré. Nécessite que toutes les bases de données soient configurées pour se connecter en tant qu’utilisateur spécifique. En outre, la base de données console autorise tout utilisateur à se connecter en tant qu’administrateur.
hba: Le type d’authentification réel est chargé à partir de auth_hba_file. Cela permet d’utiliser différentes méthodes d’authentification pour différents chemins d’accès, par exemple : les connexions via socket Unix utilisent la méthode d’authentification peer, les connexions via TCP doivent utiliser TLS.
ldap: Les utilisateurs sont authentifiés contre un serveur LDAP, comme dans PostgreSQL (voir https://www.postgresql.org/docs/current/auth-ldap.html pour les détails). Les options de connexion LDAP sont configurées à l’aide du paramètre auth_ldap_options, ou de manière alternative dans auth_hba_file.
pam: PAM est utilisé pour authentifier les utilisateurs, auth_file est ignoré. Cette méthode n’est pas compatible avec les bases de données utilisant l’option auth_user. Le nom de service transmis à PAM est « pgbouncer ». pam n’est pas pris en charge dans le fichier de configuration HBA.

auth_hba_file

Fichier de configuration HBA à utiliser lorsque auth_type est hba. Voir la section Format du fichier HBA ci-dessous pour les détails.

Par défaut : non défini

fichier_auth_ident

Fichier de mappage d’identité à utiliser lorsque auth_type est hba et qu’un mappage d’utilisateur sera défini. Voir la section Format du fichier de mappage d’identité ci-dessous pour les détails.

Par défaut : non défini

fichier_auth

Nom du fichier à charger pour les noms d’utilisateur et les mots de passe. Voir la section Format du fichier d’authentification ci-dessous pour les détails.

La plupart des types d’authentification (voir ci-dessus) exigent que soit défini auth_file soit auth_user ; sinon, aucun utilisateur ne serait défini.

Par défaut : non défini

auth_user

Si auth_user est défini, tout utilisateur non spécifié dans auth_file sera interrogé via la requête auth_query depuis pg_authid dans la base de données, en utilisant auth_user. Le mot de passe de auth_user sera extrait de auth_file. (Si auth_user n’exige pas de mot de passe, alors il n’est pas nécessaire de le définir dans auth_file.)

L’accès direct à pg_authid nécessite des droits d’administrateur. Il est préférable d’utiliser un utilisateur non superutilisateur qui appelle une fonction définie en tant que SECURITY DEFINER.

Par défaut : non défini

auth_query

Requête permettant de charger le mot de passe de l’utilisateur depuis la base de données.

Notez que la requête s’exécute dans la base de données cible. Ainsi, si une fonction est utilisée, elle doit être installée dans chaque base de données.

Valeur par défaut : SELECT rolname, CASE WHEN rolvaliduntil < now() THEN NULL ELSE rolpassword END FROM pg_authid WHERE rolname=$1 AND rolcanlogin

auth_dbname

Nom de la base de données dans la section [database] à utiliser à des fins d’authentification. Cette option peut être globale ou remplacée dans la chaîne de connexion si ce paramètre est spécifié.

auth_ldap_options

Options de connexion LDAP à utiliser si auth_type est ldap. (Non utilisées si l’authentification est configurée via auth_hba_file.) Exemple :

auth_ldap_options = ldapurl="ldap://127.0.0.1:12345/dc=example,dc=net?uid?sub"

Paramètres de journalisation

journal système

Active ou désactive le journalisation syslog. Sous Windows, le journal des événements est utilisé à la place.

Valeur par défaut : 0

syslog_ident

Sous quel nom envoyer les journaux à syslog.

Par défaut : pgbouncer (nom du programme)

facility_syslog

Sur quelle installation envoyer les journaux vers syslog. Possibilités : auth, authpriv, daemon, user, local0-7.

Valeur par défaut : daemon

log_connections

Enregistrer les connexions réussies.

Valeur par défaut : 1

log_disconnections

Journaliser les déconnexions avec leurs raisons.

Valeur par défaut : 1

log_pooler_errors

Enregistre les messages d’erreur que le pooler envoie aux clients.

Valeur par défaut : 1

log_stats

Écrire les statistiques agrégées dans le journal toutes les stats_period. Cette fonction peut être désactivée si des outils de surveillance externes sont utilisés pour récupérer les mêmes données à partir des commandes SHOW.

Valeur par défaut : 1

verbose

Augmenter le niveau de verbosité. Correspond à l’option -v en ligne de commande. Par exemple, utiliser -v -v en ligne de commande équivaut à verbose=2. 3 est le niveau de verbosité le plus élevé actuellement pris en charge.

Valeur par défaut : 0

Contrôle d’accès à la console

administrateurs

Liste séparée par des virgules des utilisateurs de base de données autorisés à se connecter et à exécuter toutes les commandes sur la console d’administration. Ignorée lorsque auth_type est égal à any, auquel cas tout nom d’utilisateur est autorisé en tant qu’administrateur.

Par défaut : vide

stats_users

Liste séparée par des virgules des utilisateurs de base de données autorisés à se connecter et à exécuter des requêtes en lecture seule sur la console. Cela signifie toutes les commandes SHOW sauf SHOW FDS.

Par défaut : vide

Vérifications de santé des connexions, délais d’attente

reset_query_serveur

Requête envoyée au serveur lors de la libération de la connexion, avant de la rendre disponible aux autres clients. À ce moment, aucune transaction n’est en cours, donc la valeur ne doit pas inclure ABORT ni ROLLBACK.

La requête doit nettoyer tout changement apporté à la session de base de données afin que le client suivant obtienne une connexion dans un état défini. La valeur par défaut est DISCARD ALL, qui supprime tout, mais cela laisse le client suivant sans état pré-caché. Elle peut être rendue plus légère, par exemple DEALLOCATE ALL, qui ne supprime que les requêtes préparées, si l’application ne se dérègle pas lorsque certaines informations sont conservées.

Lorsqu’un pooling de transactions est utilisé, le server_reset_query n’est pas utilisé, car, en ce mode, les clients ne doivent pas utiliser de fonctionnalités liées à la session, puisque chaque transaction est effectuée sur une connexion différente et donc dans un état de session différent.

Valeur par défaut : DISCARD ALL

server_reset_query_always

Si server_reset_query doit être exécuté dans tous les modes de pool. Lorsque ce paramètre est désactivé (valeur par défaut), server_reset_query ne sera exécuté que dans les pools en mode poolisation de sessions. Les connexions en mode poolisation de transactions n’ont pas besoin d’une requête de réinitialisation.

Ce paramètre sert à contourner les configurations défectueuses qui exécutent des applications utilisant des fonctionnalités de session sur un PgBouncer configuré en poolage par transaction. Il transforme une panne aléatoire en une panne déterministe : les clients perdent toujours leur état après chaque transaction.

Valeur par défaut : 0

délai_vérification_serveur

Durée pendant laquelle les connexions libérées sont conservées disponibles pour une réutilisation immédiate, sans exécuter server_check_query sur celle-ci. Si la valeur est 0, le contrôle est toujours exécuté.

Par défaut : 30.0

server_check_query

Requête simple sans action pour vérifier si la connexion au serveur est active.

Si une chaîne vide, alors la vérification de cohérence est désactivée.

Si <empty>, envoyer une requête vide en tant que vérification de cohérence.

Valeur par défaut : <empty>

server_fast_close

Déconnecte un serveur en mode pooling de sessions immédiatement ou après la fin de la transaction en cours s’il est en mode “close_needed” (défini par RECONNECT, RELOAD modifiant les paramètres de connexion ou un changement DNS), plutôt que d’attendre la fin de la session. En mode pooling de transactions ou pooling d’instructions, cela n’a aucun effet, car c’est le comportement par défaut dans ces modes.

Si, en raison de ce paramètre, une connexion serveur est fermée avant la fin de la session client, la connexion client est également fermée. Cela garantit que le client détecte que la session a été interrompue.

Ce paramètre permet que les modifications de configuration de connexion prennent effet plus rapidement lorsque le pooling de sessions et des sessions longues sont utilisés. Le désavantage est que les sessions clients risquent d’être interrompues par un changement de configuration, ce qui impose aux applications clientes de prévoir une logique de reconnexion et de rétablissement de l’état de session. Toutefois, notez qu’aucune transaction en cours ne sera perdue, car les transactions en cours ne sont pas interrompues, uniquement les sessions inactives.

Valeur par défaut : 0

durée_de_vie_serveur

Le pooler fermera une connexion serveur inutilisée (non actuellement liée à une connexion client) qui a été établie depuis plus longtemps que cette durée. Une valeur de 0 signifie que la connexion ne doit être utilisée qu’une seule fois, puis fermée. [secondes]

Cela peut également être défini par base de données dans la section [databases].

Par défaut : 3600.0

server_idle_timeout

Si une connexion vers un serveur est restée inactif plus de ce nombre de secondes, elle sera fermée. Si cette valeur est 0, ce délai d’expiration est désactivé. [secondes]

Par défaut : 600.0

server_connect_timeout

Si la connexion et la connexion à l’utilisateur ne sont pas terminées dans cet intervalle, la connexion sera fermée. [secondes]

Par défaut : 15.0

tentative_de_connexion_au_serveur_avec_reconnexion

Si la connexion au serveur échoue, en raison d’un échec de connexion ou d’une authentification, le pooler attend cette durée avant de tenter à nouveau de se connecter. Pendant l’intervalle d’attente, les nouveaux clients tentant de se connecter au serveur défaillant obtiennent immédiatement une erreur, sans autre tentative de connexion. [secondes]

Le but de ce comportement est que les clients ne s’accumulent pas inutilement en attente d’une connexion serveur lorsque ce dernier n’est pas opérationnel. Toutefois, cela signifie également qu’en cas de défaillance temporaire du serveur, par exemple lors d’un redémarrage ou en cas de configuration erronée, le pooler ne tentera de se reconnecter à celui-ci qu’au moins après cette durée. Les événements planifiés, tels que les redémarrages, doivent normalement être gérés à l’aide de la commande PAUSE afin d’éviter ce délai.

Par défaut : 15.0

client_login_timeout

Si un client se connecte mais ne parvient pas à se connecter dans ce délai, il sera déconnecté. Nécessaire principalement pour éviter les connexions mortes bloquant SUSPEND et empêchant ainsi le redémarrage en ligne. [secondes]

Par défaut : 60.0

autodb_idle_timeout

Si les pools de bases de données créés automatiquement (via *) n’ont pas été utilisés pendant ce nombre de secondes, ils sont libérés. L’inconvénient de cette approche est qu’ils perdent également leurs statistiques. [secondes]

Par défaut : 3600.0

dns_max_ttl

Durée de mise en mémoire tampon des requêtes DNS. Le TTL réel DNS est ignoré. [secondes]

Par défaut : 15.0

dns_nxdomain_ttl

Durée de mise en cache des erreurs DNS et des requêtes DNS NXDOMAIN. [secondes]

Par défaut : 15.0

période_vérification_zone_dns

Période d’inspection pour détecter un changement du numéro de série d’une zone.

PgBouncer peut collecter des zones DNS à partir des noms d’hôte (tout ce qui suit le premier point) et vérifier périodiquement si le numéro de série de la zone a changé. Si une modification est détectée, tous les noms d’hôte de cette zone sont à nouveau résolus. Si l’adresse IP d’un hôte change, ses connexions sont invalidées.

Fonctionne uniquement avec le backend c-ares (configure option --with-cares).

Par défaut : 0.0 (désactivé)

fichier_resolv_conf

Emplacement d’un fichier resolv.conf personnalisé. Cela permet de spécifier des serveurs DNS personnalisés et éventuellement d’autres options de résolution de noms, indépendamment de la configuration globale du système d’exploitation.

Exige un backend evdns (>= 2.0.3) ou c-ares (>= 1.15.0).

L’analyse du fichier est effectuée par la bibliothèque backend DNS, et non par PgBouncer ; reportez-vous à la documentation de la bibliothèque pour obtenir les détails sur la syntaxe et les directives autorisées.

Par défaut : vide (utiliser les paramètres par défaut du système d’exploitation)

query_wait_notify

Délai pendant lequel un client sera mis en file d’attente avant que PgBouncer n’envoie un message de notification indiquant qu’il est en file d’attente. [secondes]

Une valeur de 0 désactive ce message de notification.

Valeur par défaut : 5

Paramètres TLS

Si le contenu de l’un des fichiers cert ou key est modifié sans changer le nom de fichier réel dans la configuration, les nouveaux contenus seront utilisés pour les nouvelles connexions après une relecture. Les connexions existantes ne seront toutefois pas fermées. Si, pour des raisons de sécurité, il est nécessaire que toutes les connexions utilisent les nouveaux fichiers dès que possible, il est conseillé d’exécuter RECONNECT après la relecture.

Modifier l’un quelconque paramètre TLS déclenche automatiquement une RECONNECT pour des raisons de sécurité.

client_tls_sslmode

Mode TLS à utiliser pour les connexions provenant des clients. Les connexions TLS sont désactivées par défaut. Lorsqu’elles sont activées, client_tls_key_file et client_tls_cert_file doivent également être configurés afin de définir la clé et le certificat utilisés par PgBouncer pour accepter les connexions clients. Le format de fichier de certificat le plus courant utilisable par PgBouncer est PEM.

disable: TCP brut. Si le client demande TLS, cela est ignoré. Valeur par défaut.
allow: Si le client demande TLS, il est utilisé. Sinon, TCP brut est utilisé. Si le client présente un certificat client, il n’est pas validé.
prefer: Identique à allow.
require: Le client doit utiliser TLS. Sinon, la connexion est rejetée. Si le client présente un certificat client, il n’est pas validé.
verify-ca: Le client doit utiliser TLS avec un certificat client valide.
verify-full: Identique à verify-ca.

client_tls_key_file

Clé privée de PgBouncer pour accepter les connexions clients.

Par défaut : non défini

client_tls_cert_file

Certificat associé à la clé privée. Les clients peuvent le valider.

Par défaut : non défini

client_tls_ca_file

Fichier de certificat racine utilisé pour valider les certificats clients.

Par défaut : non défini

client_tls_protocols

Quelles versions du protocole TLS sont autorisées. Valeurs autorisées : tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3. Raccourcis : all (tlsv1.0,tlsv1.1,tlsv1.2,tlsv1.3), secure (tlsv1.2,tlsv1.3).

Par défaut : secure

client_tls_ciphers

Cipheres TLS autorisés, au format OpenSSL. Raccourcis :

default/secure/fast/normal (tous utilisent les paramètres par défaut OpenSSL du système)
all (active tous les chiffrements, non recommandé)

Seules les connexions utilisant la version TLS 1.2 et inférieure sont concernées. Pour la version 1.3, voir client_tls13_ciphers ci-dessous.

Valeur par défaut : default

client_tls13_ciphers

Cipheres TLS v1.3 autorisés. Si vide, il utilisera la valeur de client_tls_ciphers. Valeurs autorisées :

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

Seules les connexions utilisant TLS version 1.3 et supérieure sont concernées. Pour les versions 1.2 et inférieures, voir client_tls_ciphers.

Valeur par défaut : <empty>

client_tls_ecdhcurve

Nom de la courbe elliptique à utiliser pour les échanges de clés ECDH.

Valeurs autorisées : none (DH désactivé), auto (ECDH 256 bits), nom de courbe

Valeur par défaut : auto

client_tls_dheparams

Type d’échange de clés DHE.

Valeurs autorisées : none (DH désactivé), auto (DH 2048 bits), legacy (DH 1024 bits)

Valeur par défaut : auto

server_tls_sslmode

Mode TLS à utiliser pour les connexions aux serveurs PostgreSQL. Le mode par défaut est prefer.

disable : TCP brut. Le serveur n’est même pas interrogé pour une connexion TLS.
allow : À corriger : si le serveur rejette le mode brut, tenter TLS ?
prefer : Une connexion TLS est toujours demandée en premier au serveur PostgreSQL. Si elle est refusée, la connexion est établie en TCP brut. Le certificat du serveur n’est pas validé. Valeur par défaut.
require : La connexion doit obligatoirement s’établir en TLS. Si le serveur la refuse, la connexion en TCP brut n’est pas tentée. Le certificat du serveur n’est pas validé.
verify-ca : La connexion doit obligatoirement s’établir en TLS et le certificat du serveur doit être valide selon server_tls_ca_file. Le nom d’hôte du serveur n’est pas vérifié par rapport au certificat.
verify-full : La connexion doit obligatoirement s’établir en TLS et le certificat du serveur doit être valide selon server_tls_ca_file. Le nom d’hôte du serveur doit correspondre aux informations du certificat.

server_tls_ca_file

Fichier de certificat racine utilisé pour valider les certificats des serveurs PostgreSQL.

Par défaut : non défini

fichier_cle_tls_serveur

Clé privée de PgBouncer pour s’authentifier auprès du serveur PostgreSQL.

Par défaut : non défini

server_tls_cert_file

Certificat associé à la clé privée. Le serveur PostgreSQL peut le valider.

Par défaut : non défini

server_tls_protocols

Quelles versions du protocole TLS sont autorisées. Valeurs autorisées : tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3. Raccourcis : all (tlsv1.0,tlsv1.1,tlsv1.2,tlsv1.3), secure (tlsv1.2,tlsv1.3), legacy (all).

Par défaut : secure

server_tls_ciphers

Cipheres TLS autorisés, au format OpenSSL. Raccourcis :

default/secure/fast/normal (tous utilisent les paramètres par défaut OpenSSL du système)
all (active tous les chiffrements, non recommandé)

Seules les connexions utilisant la version TLS 1.2 et inférieures sont concernées. Pour la version 1.3, voir server_tls13_ciphers ci-dessous.

Valeur par défaut : default

server_tls13_ciphers

Cipheres TLS v1.3 autorisés. Si vide, il utilisera la valeur de server_tls_ciphers. Valeurs autorisées :

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

Seules les connexions utilisant TLS version 1.3 et supérieure sont concernées. Pour les versions 1.2 et inférieures, voir client_tls_ciphers.

Valeur par défaut : <empty>

Délais d’attente dangereux

Définir les délais suivants peut entraîner des erreurs imprévues.

query_timeout

Requêtes exécutées plus longtemps que ce délai sont annulées. Cette option doit être utilisée uniquement avec une valeur légèrement plus petite pour le paramètre côté serveur statement_timeout, afin de ne s’appliquer qu’en cas de problèmes réseau. [secondes]

Par défaut : 0.0 (désactivé)

query_wait_timeout

Temps maximal autorisé aux requêtes pour attendre leur exécution. Si la requête n’est pas affectée à un serveur pendant cette durée, le client est déconnecté. La valeur 0 désactive cette fonctionnalité. Si cette option est désactivée, les clients seront mis en file d’attente indéfiniment. [secondes]

Ce paramètre est utilisé pour empêcher les serveurs inactifs de consommer des connexions. Il est également utile lorsque le serveur est hors ligne ou refuse les connexions pour quelque raison que ce soit.

Par défaut : 120.0

timeout_attente_annulation

Temps maximal autorisé pour les demandes de annulation en attente d’exécution. Si la demande d’annulation n’est pas affectée à un serveur pendant cette durée, le client est déconnecté. 0 désactive cette fonctionnalité. Si cette option est désactivée, les demandes d’annulation seront mises en file d’attente indéfiniment. [secondes]

Ce paramètre est utilisé pour empêcher qu’un client se bloque lorsque l’annulation ne peut être acheminée en raison de la panne du serveur.

Par défaut : 10.0

délai d’inactivité du client

Les connexions clients inactives depuis plus de ce nombre de secondes sont fermées. Cette valeur doit être supérieure aux paramètres de durée de vie des connexions côté client, et n’est utilisée qu’en cas de problèmes réseau. [secondes]

Par défaut : 0.0 (désactivé)

idle_transaction_timeout

Si un client reste plus longtemps dans l’état « idle in transaction », il sera déconnecté. [secondes]

Par défaut : 0.0 (désactivé)

transaction_timeout

Si un client reste plus longtemps dans l’état « en transaction », il sera déconnecté. [secondes]

Par défaut : 0.0 (désactivé)

délai_d’attente_suspendu

Durée d’attente pour l’écriture du tampon pendant un SUSPEND ou un redémarrage (-R). Une connexion est fermée si l’écriture échoue. [secondes]

Valeur par défaut : 10

Paramètres réseau de bas niveau

tampon_paquet

Taille du tampon interne pour les paquets. Influence la taille des paquets TCP envoyés et l’utilisation mémoire globale. Les paquets réels libpq peuvent être plus grands que cette valeur, il n’est donc pas nécessaire de la définir élevée.

Valeur par défaut : 4096

taille_max_paquet

Taille maximale des paquets PostgreSQL autorisés par PgBouncer. Un paquet correspond soit à une requête, soit à une ligne d’un jeu de résultats. Le jeu de résultats complet peut être plus grand.

Valeur par défaut : 2147483647

listen_backlog

Argument Backlog pour listen(2). Détermine le nombre de nouvelles tentatives de connexion non traitées conservées dans la file d’attente. Lorsque la file est pleine, les nouvelles connexions supplémentaires sont rejetées.

Valeur par défaut : 128

sbuf_loopcnt

Nombre de fois où les données doivent être traitées sur une connexion avant de passer à l’étape suivante. Sans cette limite, une connexion avec un grand jeu de résultats peut bloquer PgBouncer pendant une longue période. Une boucle traite une quantité de données égale à pkt_buf. La valeur 0 signifie qu’aucune limite n’est appliquée.

Valeur par défaut : 5

so_reuseport

Spécifie si l’option de socket SO_REUSEPORT doit être définie sur les sockets TCP d’écoute. Sur certains systèmes d’exploitation, cela permet d’exécuter plusieurs instances de PgBouncer sur le même hôte, écoutant sur le même port, avec une répartition automatique des connexions par le noyau. Cette option permet à PgBouncer d’utiliser davantage de cœurs processeurs. (PgBouncer est monothread et utilise un cœur processeur par instance.)

Le comportement en détail dépend du noyau du système d’exploitation. À la date de rédaction de ce document, ce paramètre produit l’effet souhaité sur Linux (versions suffisamment récentes), DragonFlyBSD et FreeBSD. (Sur FreeBSD, il applique l’option de socket SO_REUSEPORT_LB à la place.) Certains autres systèmes d’exploitation prennent en charge l’option de socket, mais celle-ci n’aura pas l’effet souhaité : elle permettra à plusieurs processus de se lier au même port, mais seul l’un d’entre eux recevra les connexions. Consultez la documentation de votre système d’exploitation concernant setsockopt() pour plus de détails.

Sur les systèmes qui ne prennent pas du tout en charge l’option de socket, activer ce paramètre entraînera une erreur.

Chaque instance de PgBouncer sur le même hôte doit disposer de paramètres différents au moins pour unix_socket_dir et pidfile, ainsi que pour logfile si celui-ci est utilisé. Notez également que, si vous utilisez cette option, il devient impossible de se connecter à une instance spécifique de PgBouncer via TCP/IP, ce qui peut avoir des implications pour la surveillance et la collecte de métriques.

Pour garantir que les annulations de requêtes fonctionnent correctement, vous devez configurer une réplication entre les différents processus PgBouncer. Pour plus de détails, reportez-vous à la documentation relative à l’option de configuration peer_id et à la section de configuration peers. Un exemple utilisant la réplication et so_reuseport est également disponible dans la section d’exemples de ces documents.

Valeur par défaut : 0

tcp_defer_accept

Définit l’option de socket TCP_DEFER_ACCEPT ; consultez man 7 tcp pour les détails. (Il s’agit d’une option booléenne : 1 signifie activée. La valeur réelle définie lorsqu’elle est activée est actuellement codée en dur à 45 secondes.)

Cela n’est actuellement pris en charge que sous Linux.

Valeur par défaut : 1 sous Linux, sinon 0

tcp_socket_buffer

Par défaut : non défini

tcp_keepalive

Active la fonctionnalité de keepalive basique avec les paramètres par défaut du système d’exploitation.

Sur Linux, les valeurs par défaut du système sont tcp_keepidle=7200, tcp_keepintvl=75, tcp_keepcnt=9. Elles sont probablement similaires sur d’autres systèmes d’exploitation.

Valeur par défaut : 1

tcp_keepcnt

Par défaut : non défini

tcp_keepidle

Par défaut : non défini

tcp_keepintvl

Par défaut : non défini

tcp_user_timeout

Définit l’option de socket TCP_USER_TIMEOUT. Cela précise la durée maximale, en millisecondes, pendant laquelle les données transmises peuvent rester non reconnues avant que la connexion TCP ne soit fermée de force. Si cette valeur est définie à 0, la valeur par défaut du système d’exploitation est utilisée.

Cela n’est actuellement pris en charge que sous Linux.

Valeur par défaut : 0

Section [databases]

La section [databases] définit les noms des bases de données auxquelles les clients de PgBouncer peuvent se connecter et précise où ces connexions seront acheminées. La section contient des lignes key=value telles que

dbname = connection string

où la clé sera prise comme nom de base de données et la valeur comme chaîne de connexion, composée de paires clé=valeur de paramètres de connexion, décrites ci-dessous (similaire à libpq, mais la bibliothèque libpq réelle n’est pas utilisée et l’ensemble des fonctionnalités disponibles est différent). Exemple :

foodb = host=host1.example.com port=5432
bardb = host=localhost dbname=bazdb

Le nom de base de données peut contenir des caractères _0-9A-Za-z sans guillemets. Les noms contenant d’autres caractères doivent être cités entre guillemets standard selon la syntaxe SQL : guillemets doubles, avec "" pour une occurrence unique de guillemet double.

Le nom de base de données pgbouncer est réservé à la console d’administration et ne peut pas être utilisé comme clé ici.

* agit comme base de données de secours : si le nom exact n’existe pas, sa valeur est utilisée comme chaîne de connexion pour la base de données demandée. Par exemple, si une entrée existe (et aucune autre entrée ne l’override)

* = host=foo

puis une connexion à PgBouncer spécifiant une base de données bar se comportera effectivement comme si une entrée existait

bar = host=foo dbname=bar

existe (en profitant de la valeur par défaut de dbname étant le nom de la base côté client ; voir ci-dessous).

Les entrées de base de données créées automatiquement sont supprimées si elles restent inactives plus longtemps que le délai spécifié par le paramètre autodb_idle_timeout.

dbname

Nom de la base de données de destination.

Valeur par défaut : identique au nom de la base du côté client

hôte

Nom d’hôte ou adresse IP vers laquelle se connecter. Les noms d’hôte sont résolus au moment de la connexion, le résultat est mis en mémoire tampon par paramètre dns_max_ttl. Lorsqu’une résolution de nom d’hôte change, les connexions serveur existantes sont automatiquement fermées lorsqu’elles sont libérées (selon le mode de regroupement), et les nouvelles connexions serveur utilisent immédiatement la nouvelle résolution. Si DNS retourne plusieurs résultats, ils sont utilisés de manière cyclique.

Si la valeur commence par /, un socket Unix dans l’espace de noms du système de fichiers est utilisé. Si la valeur commence par @, un socket Unix dans l’espace de noms abstrait est utilisé.

Une liste séparée par des virgules d’hôtes ou d’adresses peut être spécifiée. Dans ce cas, les connexions sont établies de manière cyclique. (Si une liste d’hôtes contient des noms d’hôtes qui se résolvent eux-mêmes via DNS en plusieurs adresses, les systèmes de rotation opèrent de manière indépendante. Il s’agit d’une dépendance d’implémentation susceptible de changer.) Notez qu’une liste exige que tous les hôtes soient disponibles en permanence : aucun mécanisme n’existe pour ignorer les hôtes inaccessibles ou sélectionner uniquement les hôtes disponibles dans la liste ou similaire. (Cela diffère de ce qu’une liste d’hôtes dans libpq signifie.) Notez également que cela n’a d’effet que sur le choix des destinations des nouvelles connexions. Voir également le paramètre server_round_robin pour savoir comment les clients sont affectés aux connexions serveur déjà établies.

Exemples :

host=localhost
host=127.0.0.1
host=2001:0db8:85a3:0000:0000:8a2e:0370:7334
host=/var/run/postgresql
host=192.168.0.1,192.168.0.2,192.168.0.3

Par défaut : non défini, ce qui signifie utiliser une socket Unix

port

Valeur par défaut : 5432

utilisateur

Si user= est défini, toutes les connexions à la base de données cible seront établies avec l’utilisateur spécifié, ce qui signifie qu’il n’y aura qu’un seul pool pour cette base de données.

Sinon, PgBouncer se connecte à la base de données de destination avec le nom d’utilisateur du client, ce qui signifie qu’il y aura un pool par utilisateur.

mot de passe

Si aucun mot de passe n’est spécifié ici, le mot de passe provenant de auth_file sera utilisé pour l’utilisateur indiqué ci-dessus. Les formes dynamiques de découverte de mot de passe telles que auth_query ne sont pas actuellement prises en charge.

auth_user

Remplacement du paramètre global auth_user, le cas échéant.

auth_query

Remplacement du paramètre global auth_query, le cas échéant. L’intégralité de l’instruction SQL doit être entourée de guillemets simples.

auth_dbname

Remplacement du paramètre global auth_dbname, le cas échéant.

taille_pool

Définir la taille maximale des pools pour cette base de données. Si ce paramètre n’est pas défini, la valeur de default_pool_size est utilisée.

taille_min_pool

Définir la taille minimale du pool pour cette base de données. Si ce paramètre n’est pas défini, la valeur globale min_pool_size est utilisée.

Imposé uniquement si au moins l’une des conditions suivantes est vraie :

cette entrée dans la section [database] a une valeur définie pour la clé user (alias utilisateur forcé)
il y a au moins un client connecté à la pool

taille_piscine_reserve

Définir un nombre supplémentaire de connexions pour cette base de données. Si ce paramètre n’est pas défini, la valeur globale reserve_pool_size est utilisée. Pour des raisons de compatibilité descendante, reserve_pool est un alias de cette option.

query_de_connexion

Requête à exécuter après établissement d’une connexion, mais avant de permettre à tout client de l’utiliser. Si la requête génère des erreurs, celles-ci sont journalisées, mais ignorées dans les autres cas.

mode_pool

Définissez le mode de pool spécifique à cette base de données. Si ce paramètre n’est pas défini, le mode par défaut pool_mode est utilisé.

load_balance_hosts

Lorsqu’une liste séparée par des virgules est spécifiée dans host, load_balance_hosts détermine quel élément est sélectionné pour une nouvelle connexion.

Note : Ce paramètre contrôle actuellement uniquement le comportement de répartition de charge lorsqu’un string de connexion contient plusieurs hôtes, mais pas lorsqu’un enregistrement DNS d’un hôte unique fait référence à plusieurs adresses IP. Il s’agit d’une fonctionnalité manquante, donc dans une version future, ce paramètre pourrait commencer à contrôler les deux méthodes de répartition de charge.

round-robin : Une nouvelle tentative de connexion choisit l’entrée hôte suivante dans la liste.
disable : Une nouvelle connexion continue d’utiliser la même entrée hôte jusqu’à ce qu’une connexion échoue, après quoi l’entrée hôte suivante est choisie.

Il est recommandé de définir server_login_retry à une valeur inférieure à celle par défaut afin d’assurer des tentatives rapides lorsqu’un ou plusieurs hôtes sont disponibles.

Valeur par défaut : round-robin

max_connexions_base_données

Définir un maximum de connexions serveur au niveau de la base de données (c’est-à-dire que toutes les pools au sein de la base de données ne comporteront pas plus de ce nombre de connexions serveur).

max_conn_client_base_données

Configure le nombre maximum de connexions clients au niveau de la base de données. Doit être utilisé en conjonction avec max_client_conn afin de limiter le nombre de connexions que PgBouncer est autorisé à accepter.

durée_de_vie_serveur

Configurez server_lifetime par base de données. Si ce paramètre n’est pas défini, la base de données utilisera la valeur configurée au niveau de l’instance pour server_lifetime.

client_encoding

Demandez un client_encoding spécifique au serveur.

datestyle

Demandez le datestyle spécifique au serveur.

fuseau horaire

Demandez le timezone spécifique au serveur.

Section [users]

Cette section contient des lignes key=value telles que

user1 = settings

où la clé sera prise comme nom d’utilisateur et la valeur comme liste de paires clé=valeur de paramètres de configuration spécifiques à cet utilisateur. Exemple :

user1 = pool_mode=session

Seuls quelques paramètres sont disponibles ici.

Notez que lorsque auth_file est configuré, si un utilisateur est défini dans cette section mais non listé dans auth_file, PgBouncer tentera d’utiliser auth_query pour trouver le mot de passe de cet utilisateur si auth_user est défini. Si auth_user n’est pas défini, PgBouncer supposera que l’utilisateur existe et ne renverra pas de message « utilisateur introuvable » au client, mais il n’acceptera non plus aucun mot de passe fourni.

taille_pool

Définir la taille maximale des pools pour toutes les connexions de cet utilisateur. Si non défini, la base de données ou default_pool_size est utilisée.

taille_piscine_reserve

Définir le nombre de connexions supplémentaires autorisées à une pool pour cet utilisateur. Si ce paramètre n’est pas défini, la configuration de la base de données ou le reserve_pool_size global est utilisée.

mode_pool

Définir le mode de pool à utiliser pour toutes les connexions de cet utilisateur. Si non défini, le mode défini dans la base de données ou la valeur par défaut pool_mode est utilisé.

max_user_connections

Définir un maximum pour le nombre de connexions serveur par utilisateur (c’est-à-dire que tous les pools associés à l’utilisateur ne comporteront pas plus de ce nombre de connexions serveur).

query_timeout

Définissez le nombre maximal de secondes pendant lesquelles une requête utilisateur peut s’exécuter. Si ce délai est défini, il remplace le paramètre query_timeout au niveau du serveur décrit ci-dessus.

idle_transaction_timeout

Définissez le nombre maximum de secondes pendant lesquelles une transaction inactif peut rester ouverte pour un utilisateur. Si ce délai est défini, il remplace le paramètre idle_transaction_timeout au niveau du serveur décrit ci-dessus.

transaction_timeout

Définissez le nombre maximum de secondes pendant lesquelles une transaction peut rester ouverte pour un utilisateur. Si ce paramètre est défini, il remplace le délai d’attente au niveau du serveur transaction_timeout décrit ci-dessus.

délai d’inactivité du client

Définissez le délai maximal en secondes pendant lequel un client est autorisé à rester connecté sans activité à l’instance PgBouncer. Si ce délai est défini, il remplace le paramètre client_idle_timeout au niveau du serveur décrit ci-dessus.

Veuillez noter qu’il s’agit d’un délai d’attente potentiellement dangereux.

max_user_client_connections

Définir un maximum pour le nombre de connexions clients par utilisateur. Il s’agit de l’équivalent utilisateur de la configuration max_client_conn.

Section [peers]

La section [peers] définit les pairs auxquels PgBouncer peut acheminer les requêtes d’annulation et l’emplacement vers lequel ces requêtes d’annulation seront acheminées.

Les processus PgBouncer peuvent être associés en groupe en définissant une valeur peer_id et une section [peers] dans les configurations de tous les processus PgBouncer. Ces processus PgBouncer peuvent alors transférer les requêtes d’annulation vers le processus d’origine. Cela est nécessaire pour assurer le bon fonctionnement des annulations lorsque plusieurs processus PgBouncer (éventuellement sur des serveurs différents) sont situés derrière le même équilibreur de charge TCP. Les requêtes d’annulation sont envoyées via des connexions TCP différentes de celles de la requête qu’elles annulent, si bien qu’un équilibreur de charge TCP pourrait acheminer la connexion de requête d’annulation vers un processus différent de celui visé. En les associant, ces requêtes d’annulation parviennent finalement au bon processus. Une explication plus détaillée est fournie dans cette enregistrement d’une conférence .

La section contient des lignes key=value telles que

peer_id = connection string

Où la clé sera utilisée comme peer_id et la valeur comme chaîne de connexion, composée de paires clé=valeur de paramètres de connexion, décrites ci-dessous (similaire à libpq, mais la bibliothèque libpq n’est pas utilisée et l’ensemble des fonctionnalités disponibles est différent). Exemple :

1 = host=host1.example.com
2 = host=/tmp/pgbouncer-2  port=5555

Note 1 : Pour que le peering fonctionne, l’peer_id de chaque processus PgBouncer du groupe doit être unique au sein du groupe peered. La section [peers] doit contenir une entrée pour chaque identifiant de pair. Un exemple est disponible dans la section exemples de ces documents. Il est autorisé, mais non obligatoire, que la section [peers] contienne l’peer_id du PgBouncer pour lequel la configuration est définie. Une telle entrée sera ignorée, mais cette pratique est autorisée afin de faciliter la gestion des configurations. Elle permet d’utiliser la même section [peers] pour plusieurs configurations.

Note 2 : Le rattachement entre versions différentes est pris en charge à condition que tous les pairs soient du même côté de la limite de version v1.21.0. La version v1.21.0 a introduit des modifications importantes dans la manière dont les jetons d’annulation sont encodés, les rendant incompatibles avec ceux générés par les versions antérieures.

hôte

Nom d’hôte ou adresse IP vers laquelle se connecter. Les noms d’hôte sont résolus au moment de la connexion, le résultat est mis en mémoire tampon par paramètre dns_max_ttl. Si DNS retourne plusieurs résultats, ils sont utilisés de manière cyclique. Toutefois, il n’est généralement pas recommandé d’utiliser un nom d’hôte qui résout vers plusieurs adresses IP, car la requête d’annulation pourrait encore être acheminée vers le mauvais nœud, ce qui nécessiterait un nouvel acheminement (autorisé au maximum trois fois).

Exemples :

host=localhost
host=127.0.0.1
host=2001:0db8:85a3:0000:0000:8a2e:0370:7334
host=/var/run/pgbouncer-1

port

Par défaut : 6432

taille_pool

Définissez le nombre maximal de demandes d’annulation pouvant être en cours vers le pair en même temps. Il est tout à fait normal que des demandes d’annulation arrivent par vagues, par exemple lorsque le serveur Postgres sous-jacent est lent ou hors service. Il est donc important que pool_size ne soit pas trop bas afin de pouvoir gérer ces vagues.

Si ce n’est pas défini, default_pool_size est utilisé.

Directive include

Le fichier de configuration de PgBouncer peut contenir des directives include, qui spécifient un autre fichier de configuration à lire et à traiter. Cela permet de diviser le fichier de configuration en parties physiquement séparées. Les directives include ont la forme suivante :

%include filename

Si le nom de fichier n’est pas un chemin absolu, il est considéré comme relatif au répertoire de travail courant.

Format de fichier d’authentification

Cette section décrit le format du fichier spécifié par le paramètre auth_file. Il s’agit d’un fichier texte au format suivant :

"username1" "password" ...
"username2" "md5abcdef012342345" ...
"username2" "SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>"

Il doit y avoir au moins 2 champs, entourés de guillemets doubles. Le premier champ est le nom d’utilisateur et le second est soit un mot de passe en clair, soit un mot de passe haché en MD5, soit un secret SCRAM. PgBouncer ignore le reste de la ligne. Les guillemets doubles dans une valeur de champ peuvent être échappés en écrivant deux guillemets doubles.

Format de mot de passe MD5 PostgreSQL :

"md5" + md5(password + username)

L’utilisateur admin avec le mot de passe 1234 disposera d’un mot de passe haché MD5 égal à md545f2603610af569b6155c45067268c6b.

Format secret SCRAM PostgreSQL :

SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>

Consultez la documentation PostgreSQL et le RFC 5803 pour plus de détails à ce sujet.

Les mots de passe ou secrets stockés dans le fichier d’authentification servent à deux fins. Premièrement, ils sont utilisés pour vérifier les mots de passe des connexions clients entrantes, si une méthode d’authentification basée sur le mot de passe est configurée. Deuxièmement, ils sont utilisés comme mots de passe pour les connexions sortantes vers le serveur backend, si le serveur backend exige une authentification basée sur le mot de passe (à moins que le mot de passe ne soit spécifié directement dans la chaîne de connexion de la base de données).

Limitations

Si le mot de passe est stocké en clair, il peut être utilisé pour toute authentification basée sur le mot de passe utilisée par le serveur backend ; clair, MD5 ou SCRAM (voir https://www.postgresql.org/docs/current/auth-password.html pour les détails).

Les mots de passe hachés MD5 peuvent être utilisés si le serveur backend utilise l’authentification MD5 (ou si certains utilisateurs ont des mots de passe hachés MD5).

Les secrets SCRAM ne peuvent être utilisés pour se connecter à un serveur que si l’authentification du client utilise également SCRAM, si la définition de la base de données dans PgBouncer ne précise pas de nom d’utilisateur, et si les secrets SCRAM sont identiques dans PgBouncer et le serveur PostgreSQL (même sel et nombre d’itérations, et non seulement le même mot de passe). Ceci est dû à une propriété de sécurité intrinsèque du SCRAM : le secret SCRAM stocké ne peut, en lui-même, être utilisé pour dériver les identifiants de connexion.

Le fichier d’authentification peut être rédigé à la main, mais il est également utile de le générer à partir d’une autre liste d’utilisateurs et de mots de passe. Consultez ./etc/mkauth.py pour un exemple de script permettant de générer le fichier d’authentification à partir de la table système pg_authid. En alternative, utilisez auth_query à la place de auth_file afin d’éviter d’avoir à maintenir un fichier d’authentification séparé.

Remarque sur les serveurs gérés

Si le serveur backend est configuré pour utiliser l’authentification par mot de passe SCRAM, PgBouncer ne peut pas s’authentifier correctement s’il ne connaît ni a) le mot de passe utilisateur en clair, ni b) le secret SCRAM correspondant.

Certains fournisseurs de cloud (par exemple, AWS RDS) interdisent l’accès aux tables système sensibles de PostgreSQL pour récupérer les mots de passe. Même pour l’utilisateur le plus privilégié (par exemple, membre de rds_superuser), select * from pg_authid retourne ERROR: permission denied for table pg_authid. Ce comportement est connu (blog ).

Par conséquent, il est impossible de récupérer un secret SCRAM existant une fois qu’il a été stocké sur un serveur géré, ce qui rend difficile la configuration de PgBouncer pour utiliser le même secret SCRAM. Toutefois, il est encore possible de configurer et d’utiliser le secret SCRAM des deux côtés en utilisant la méthode suivante :

Générez le secret SCRAM pour un mot de passe arbitraire à l’aide d’un outil capable d’afficher le secret. Par exemple, psql --echo-hidden et la commande \password affichent le secret SCRAM sur la console avant de l’envoyer au serveur.

$ psql --echo-hidden <connection_string>
postgres=# \password <role_name>
Enter new password for user "<role_name>":
Enter it again:
********* QUERY **********
ALTER USER <role_name> PASSWORD 'SCRAM-SHA-256$<iterations>:<salt>$<storedkey>:<serverkey>'
**************************

Notez le secret SCRAM issu de la requête et définissez-le dans userlist.txt de PgBouncer.

Si vous avez utilisé un outil autre que psql --echo-hidden, vous devez également définir le secret SCRAM sur le serveur (vous pouvez utiliser ALTER ROLE <role_name> PASSWORD '<scram_secret>' à cette fin).

Format du fichier HBA

L’emplacement du fichier HBA est spécifié par le paramètre auth_hba_file. Il n’est utilisé que si auth_type est défini à hba.

Le fichier suit le format du fichier PostgreSQL pg_hba.conf (voir https://www.postgresql.org/docs/current/auth-pg-hba-conf.html ).

Types de registre pris en charge : local, host, hostssl, hostnossl.
Champ base de données : prend en charge all, replication, sameuser, @file, plusieurs noms. Non pris en charge : samerole, samegroup.
Champ nom d’utilisateur : prend en charge all, @file, plusieurs noms. Non pris en charge : +groupname.
Champ adresse : prend en charge all, IPv4, IPv6. Non pris en charge : samehost, samenet, noms DNS, préfixes de domaine.
Champ méthode d’authentification : seules les méthodes prises en charge par le auth_type de PgBouncer sont prises en charge, ainsi que peer et reject, à l’exception de any et pam, qui ne fonctionnent qu’à l’échelle globale.
Le paramètre de mappage de nom d’utilisateur (map=) est pris en charge lorsque auth_type est défini à cert ou peer.

Format du fichier de mappage d’identité

L’emplacement du fichier de correspondance ident est spécifié par le paramètre auth_ident_file. Il n’est chargé que si auth_type est défini sur hba.

Le format de fichier est une variante simplifiée du fichier de correspondance ident PostgreSQL (voir https://www.postgresql.org/docs/current/auth-username-maps.html ).

Les lignes prises en charge sont uniquement au format map-name system-username database-username.
Aucun support n’est assuré pour l’inclusion de fichiers ou de répertoires.
Champ nom d’utilisateur système : non pris en charge : expressions régulières.
Champ nom d’utilisateur base de données : prend en charge all ou un seul nom d’utilisateur Postgres. Non pris en charge : +groupname, expressions régulières.

Exemples

Exemple de configuration minimaliste :

[databases]
template1 = host=localhost dbname=template1 auth_user=someuser

[pgbouncer]
pool_mode = session
listen_port = 6432
listen_addr = localhost
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser
stats_users = stat_collector

Exemples de bases de données :

[databases]

; foodb over Unix socket
foodb =

; redirect bardb to bazdb on localhost
bardb = host=localhost dbname=bazdb

; access to destination database will go with single user
forcedb = host=localhost port=300 user=baz password=foo client_encoding=UNICODE datestyle=ISO

Exemple d’une fonction sécurisée pour auth_query :

CREATE OR REPLACE FUNCTION pgbouncer.user_lookup(in i_username text, out uname text, out phash text)
RETURNS record AS $$
BEGIN
    SELECT rolname, CASE WHEN rolvaliduntil < now() THEN NULL ELSE rolpassword END
    FROM pg_authid
    WHERE rolname=i_username AND rolcanlogin
    INTO uname, phash;
    RETURN;
END;
$$ LANGUAGE plpgsql
   SECURITY DEFINER
   -- Set a secure search_path: trusted schema(s), then 'pg_temp'.
   SET search_path = pg_catalog, pg_temp;
REVOKE ALL ON FUNCTION pgbouncer.user_lookup(text) FROM public, pgbouncer;
GRANT EXECUTE ON FUNCTION pgbouncer.user_lookup(text) TO pgbouncer;

Exemples de configurations pour 2 processus PgBouncer en pairage afin de créer une configuration PgBouncer à plusieurs cœurs utilisant so_reuseport. La configuration du premier processus :

[databases]
postgres = host=localhost dbname=postgres

[peers]
1 = host=/tmp/pgbouncer1
2 = host=/tmp/pgbouncer2

[pgbouncer]
listen_addr=127.0.0.1
auth_file=auth_file.conf
so_reuseport=1
unix_socket_dir=/tmp/pgbouncer1
peer_id=1

La configuration du second processus :

[databases]
postgres = host=localhost dbname=postgres

[peers]
1 = host=/tmp/pgbouncer1
2 = host=/tmp/pgbouncer2

[pgbouncer]
listen_addr=127.0.0.1
auth_file=auth_file.conf
so_reuseport=1
; only unix_socket_dir and peer_id are different
unix_socket_dir=/tmp/pgbouncer2
peer_id=2

Voir aussi

pgBouncer(1) - page de manuel pour une utilisation générale, commandes de la console

https://www.pgbouncer.org/

3 - Usage : pgbouncer commande

Utilisation en ligne de commande et console d’administration de PgBouncer

Synopsis

pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

Sous Windows, les options sont :

pgbouncer.exe [-v][-u user] <pgbouncer.ini>
pgbouncer.exe -V|-h

Options supplémentaires pour la configuration d’un service Windows :

pgbouncer.exe --regservice   <pgbouncer.ini>
pgbouncer.exe --unregservice <pgbouncer.ini>

Description

L’objectif de pgbouncer est de réduire l’impact sur les performances lié à l’ouverture de nouvelles connexions vers PostgreSQL.

Afin de ne pas compromettre la sémantique transactionnelle pour le pooling de connexions, pgbouncer prend en charge plusieurs types de pooling lors de la rotation des connexions :

Pooling de sessions: Méthode la moins intrusive. Lorsqu’un client se connecte, une connexion serveur lui est attribuée pour toute la durée de sa connexion. Lorsque le client se déconnecte, la connexion serveur est remise dans le pool. Il s’agit de la méthode par défaut.
Pooling de transactions: Une connexion serveur est attribuée à un client uniquement pendant une transaction. Lorsque PgBouncer détecte la fin de la transaction, la connexion serveur sera remise dans le pool.
Pooling d’instructions: Méthode la plus agressive. La connexion au serveur sera immédiatement remise dans le pool après la fin d’une requête. Les transactions multi-instructions sont interdites en ce mode, car elles seraient rompues.

L’interface d’administration de pgbouncer propose de nouvelles commandes SHOW, disponibles lorsque l’on se connecte à une base de données « virtuelle » spéciale nommée pgbouncer.

Démarrage rapide

Configuration et utilisation de base se déroulent comme suit.

Créez un fichier pgbouncer.ini. Détails dans pgbouncer(5). Exemple simple :

 [databases]
 template1 = host=localhost port=5432 dbname=template1

 [pgbouncer]
 listen_port = 6432
 listen_addr = localhost
 auth_type = md5
 auth_file = userlist.txt
 logfile = pgbouncer.log
 pidfile = pgbouncer.pid
 admin_users = someuser

Créez un fichier userlist.txt contenant les utilisateurs autorisés :
```
 "someuser" "same_password_as_in_server"
```
Lancez pgbouncer :
```
 $ pgbouncer -d pgbouncer.ini
```
Faites que votre application (ou le client psql) se connecte à pgbouncer au lieu de se connecter directement au serveur PostgreSQL :
```
 $ psql -p 6432 -U someuser template1
```

Gérez pgbouncer en vous connectant à la base de données d’administration spéciale pgbouncer et en émettant SHOW HELP; pour commencer :

 $ psql -p 6432 -U someuser pgbouncer
 pgbouncer=# SHOW HELP;
 NOTICE:  Console usage
 DETAIL:
   SHOW [HELP|CONFIG|DATABASES|FDS|POOLS|CLIENTS|SERVERS|SOCKETS|LISTS|VERSION|...]
   SET key = arg
   RELOAD
   PAUSE
   SUSPEND
   RESUME
   SHUTDOWN
   [...]

Si vous avez modifié le fichier pgbouncer.ini, vous pouvez le recharger à l’aide de :
```
 pgbouncer=# RELOAD;
```

Options de ligne de commande

-d, --daemon

Exécuter en arrière-plan. Sans cette option, le processus s’exécute en premier plan.

In daemon mode, setting pidfile as well as logfile or syslog is required. No log messages will be written to stderr after going into the background.

Note: Does not work on Windows; pgbouncer need to run as service there.

-R, --reboot

OBSOLÈTE : au lieu de cette option, utilisez un redémarrage progressif avec plusieurs processus pgbouncer écoutant sur le même port en utilisant so_reuseport Effectuez un redémarrage en ligne. Cela signifie vous connecter au processus en cours d’exécution, charger les sockets ouverts depuis celui-ci, puis les utiliser. Si aucun processus actif n’est présent, démarrez normalement. Note : Fonctionne uniquement si le système d’exploitation prend en charge les sockets Unix et si unix_socket_dir n’est pas désactivé dans la configuration. Ne fonctionne pas sous Windows. Ne fonctionne pas avec les connexions TLS, celles-ci sont perdues.

-u USERNAME, --user= USERNAME

Passer à l’utilisateur spécifié au démarrage.

-v, --verbose

Augmenter le niveau de détail. Peut être utilisé plusieurs fois.

-q, --quiet

Soyez silencieux : ne pas journaliser sur stderr. Cela n’affecte pas le niveau de verbosité du journal, uniquement le fait que stderr ne doit pas être utilisé. À utiliser dans les scripts init.d.

-V, --version

Affiche la version.

-h, --help

Affiche l’aide courte.

--regservice

Win32 : inscrire PgBouncer pour s’exécuter en tant que service Windows. La valeur du paramètre de configuration service_name est utilisée comme nom d’enregistrement.

--unregservice

Win32 : Désinscrire le service Windows.

Console d’administration

La console est disponible en se connectant normalement à la base de données pgbouncer :

$ psql -p 6432 pgbouncer

Seuls les utilisateurs listés dans les paramètres de configuration admin_users ou stats_users peuvent se connecter à la console. (À moins que auth_type=any, auquel cas tout utilisateur est autorisé à se connecter en tant que stats_user.)

En outre, le nom d’utilisateur pgbouncer est autorisé à se connecter sans mot de passe, si la connexion est établie via le socket Unix et que l’utilisateur Unix du client est identique à celui du processus en cours d’exécution.

La console d’administration ne prend actuellement en charge que le protocole de requête simple. Certains pilotes utilisent le protocole de requête étendu pour toutes les commandes ; ces pilotes ne fonctionneront pas dans ce cas.

Afficher les commandes

Les commandes SHOW produisent des informations. Chaque commande est décrite ci-dessous.

MONTRER STATS

Affiche les statistiques. Dans cette commande et les commandes apparentées, les valeurs totales correspondent à partir du démarrage du processus, les moyennes sont mises à jour toutes les stats_period.

base de données: Les statistiques sont présentées par base de données.
total_xact_count: Nombre total de transactions SQL regroupées par pgbouncer.
total_query_count: Nombre total de commandes SQL regroupées par pgbouncer.
total_server_assignment_count: Nombre total d’affectations d’un serveur à un client
total_received: Volume total en octets du trafic réseau reçu par pgbouncer.
total_sent: Volume total en octets de trafic réseau envoyé par pgbouncer.
total_xact_time: Nombre total de microsecondes passées par pgbouncer lorsqu’il est connecté à PostgreSQL dans une transaction, qu’elles soient en attente ou en cours d’exécution.
total_query_time: Nombre total de microsecondes passées par pgbouncer lorsqu’il est activement connecté à PostgreSQL, en exécutant des requêtes.
total_wait_time: Temps passé par les clients en attente d’un serveur, en microsecondes. Mis à jour lorsque la connexion d’un client est associée à une connexion serveur.
total_client_parse_count: Nombre total de requêtes préparées créées par les clients. N’est applicable que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.
total_server_parse_count: Nombre total d’instructions préparées créées par pgbouncer sur un serveur. N’est applicable que dans le mode de suivi des instructions préparées nommées, voir max_prepared_statements.
total_bind_count: Nombre total de requêtes préparées lues par les clients et transférées à PostgreSQL par pgbouncer. N’est applicable que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.
avg_xact_count: Nombre moyen de transactions par seconde durant la dernière période de statistiques.
avg_query_count: Nombre moyen de requêtes par seconde durant la dernière période de statistiques.
avg_server_assignment_count: Nombre moyen de fois où un serveur est affecté à un client par seconde pendant la dernière période de statistiques.
avg_recv: Octets reçus en moyenne (par les clients) par seconde.
avg_sent: Nombre moyen d’octets envoyés (aux clients) par seconde.
avg_xact_time: Durée moyenne d’une transaction, en microsecondes.
avg_query_time: Durée moyenne d’exécution d’une requête, en microsecondes.
avg_wait_time: Temps passé par les clients en attente d’un serveur, en microsecondes (moyenne des temps d’attente des clients affectés à un backend pendant le stats_period actuel).
avg_client_parse_count: Nombre moyen de requêtes préparées créées par les clients. N’est applicable que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.
avg_server_parse_count: Nombre moyen de requêtes préparées créées par pgbouncer sur un serveur. N’est applicable que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.
avg_bind_count: Nombre moyen de requêtes préparées lues par les clients et transférées à PostgreSQL par pgbouncer. N’est applicable que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.

SHOW STATS_TOTALS

Sous-ensemble de SHOW STATS affichant les valeurs totales (total_).

SHOW STATS_AVERAGES

Sous-ensemble de SHOW STATS affichant les valeurs moyennes (avg_).

SHOW TOTALS

Comme SHOW STATS, mais agrégé pour toutes les bases de données.

SHOW SERVEURS

type: S, pour serveur.
user: Nom d’utilisateur que pgbouncer utilise pour se connecter au serveur.
base: Nom de la base de données.
réplication: Si la connexion au serveur utilise la réplication. Peut être none, logical ou physical.
state: État de la connexion du serveur PgBouncer, l’une des valeurs suivantes : active, idle, used, tested, new, active_cancel, being_canceled.
addr: Adresse IP du serveur PostgreSQL.
port: Port du serveur PostgreSQL.
local_addr: Adresse de départ de la connexion sur la machine locale.
local_port: Port de départ pour les connexions sur la machine locale.
connect_time: Date de la connexion.
request_time: Date de la dernière requête émise.
wait: Non utilisé pour les connexions serveur.
wait_us: Non utilisé pour les connexions serveur.
close_needed: 1 si la connexion sera fermée dès que possible, car un rechargement du fichier de configuration ou une mise à jour DNS a modifié les informations de connexion ou que RECONNECT a été émis.
ptr: Adresse de l’objet interne pour cette connexion.
lien: Adresse de la connexion client avec laquelle le serveur est apparié.
remote_pid: PID du processus serveur backend. En cas de connexion via un socket Unix et si le système d’exploitation prend en charge la récupération des informations sur le PID, il s’agit du PID système. Sinon, il est extrait du paquet d’annulation envoyé par le serveur, qui doit correspondre au PID si le serveur est PostgreSQL, mais il s’agit d’un nombre aléatoire si le serveur est un autre PgBouncer.
tls: Chaîne contenant les informations de connexion TLS, ou chaîne vide si TLS n’est pas utilisé.
application_name: Chaîne de caractères contenant le application_name défini sur la connexion client liée, ou vide si ce paramètre n’est pas défini, ou s’il n’existe pas de connexion liée.
instructions préparées: Le nombre d’instructions préparées effectuées sur le serveur. Ce nombre est limité par le paramètre max_prepared_statements.
id: ID unique du serveur.

MONTRER LES CLIENTS

type: C, pour client.
user: Utilisateur du client connecté.
base: Nom de la base de données.
réplication: Si la connexion client utilise la réplication. Peut être none, logical ou physical.
state: État de la connexion client, l’une des valeurs suivantes : active (connexions clients liées à des connexions serveur), idle (connexions clients sans requête en attente de traitement), waiting, active_cancel_req ou waiting_cancel_req.
addr: Adresse IP du client.
port: Port source du client.
local_addr: Adresse de bout de connexion sur la machine locale.
local_port: Port de connexion sur la machine locale.
connect_time: Horodatage de l’instant de connexion.
request_time: Horodatage de la dernière requête du client.
wait: Temps d’attente actuel en secondes.
wait_us: Partie en microsecondes du temps d’attente actuel.
close_needed: non utilisé pour les clients
ptr: Adresse de l’objet interne pour cette connexion.
lien: Adresse de la connexion serveur avec laquelle le client est apparié.
remote_pid: Identifiant de processus, au cas où le client se connecterait via une socket Unix et que le système d’exploitation le permette.
tls: Chaîne contenant les informations de connexion TLS, ou chaîne vide si TLS n’est pas utilisé.
application_name: Chaîne de caractères contenant le application_name défini par le client pour cette connexion, ou vide si ce champ n’a pas été défini.
prepared_statements: Nombre de requêtes préparées par le client
id: ID unique du client.

SHOW POOLS

Une nouvelle entrée de pool est créée pour chaque couple (base de données, utilisateur).

base: Nom de la base de données.
user: Nom d’utilisateur.
cl_active: Connexions clientes qui sont soit associées à des connexions serveur, soit inactives sans requête en attente de traitement.
cl_waiting: Connexions client qui ont envoyé des requêtes mais n’ont pas encore obtenu de connexion serveur.
cl_active_cancel_req: Connexions clientes ayant transmis des demandes d’annulation de requête au serveur et en attente de la réponse du serveur.
cl_waiting_cancel_req: Connexions clientes qui n’ont pas encore transmis les demandes d’annulation de requête au serveur.
sv_active: Connexions serveur liées à un client.
sv_active_cancel: Connexions serveur en cours d’envoi d’une demande d’annulation.
sv_being_canceled: Serveurs qui pourraient normalement devenir inactifs mais qui attendent de le devenir jusqu’à ce que toutes les demandes d’annulation en cours aient été traitées, celles-ci ayant été envoyées pour annuler une requête sur ce serveur.
sv_idle: Connexions serveur inutilisées et immédiatement disponibles pour les requêtes clients.
sv_used: Connexions serveur qui ont été inactives pendant plus de server_check_delay, donc elles nécessitent server_check_query pour pouvoir être utilisées à nouveau.
sv_tested: Connexions serveur en cours d’exécution soit server_reset_query, soit server_check_query.
sv_login: Connexions serveur actuellement en cours de connexion.
maxwait: Temps d’attente, en secondes, du premier (plus ancien) client dans la file d’attente. Si cette valeur commence à augmenter, c’est que le pool de serveurs actuel ne traite pas les requêtes assez rapidement. La cause peut être soit un serveur surchargé, soit une valeur de pool_size trop faible.
maxwait_us: Partie en microsecondes du temps d’attente maximal.
pool_mode: Le mode de mise en pool utilisé.
load_balance_hosts: Le paramètre load_balance_hosts utilisé si l’hôte du pool contient une liste séparée par des virgules.

SHOW PEER_POOLS

Une nouvelle entrée peer_pool est créée pour chaque pair configuré.

base de données: ID de l’entrée pair configurée.
cl_active_cancel_req: Connexions clientes ayant transmis des demandes d’annulation de requête au serveur et en attente de la réponse du serveur.
cl_waiting_cancel_req: Connexions clientes qui n’ont pas encore transmis les demandes d’annulation de requête au serveur.
sv_active_cancel: Connexions serveur en cours d’envoi d’une demande d’annulation.
sv_login: Connexions serveur actuellement en cours de connexion.

MONTRER LES LISTES

Affiche les informations internes suivantes, en colonnes (et non en lignes) :

bases de données: Nombre de bases de données.
utilisateurs: Nombre d’utilisateurs.
pools: Nombre de pools.
free_clients: Nombre de clients libres. Ce sont des clients déconnectés, mais PgBouncer conserve en mémoire la mémoire allouée pour eux afin de la réutiliser ultérieurement pour de nouveaux clients, afin d’éviter des allocations.
used_clients: Nombre de clients utilisés.
login_clients: Nombre de clients en état login.
free_servers: Nombre de serveurs libres. Ce sont des serveurs déconnectés, mais PgBouncer conserve en mémoire la mémoire allouée pour eux afin de la réutiliser ultérieurement pour des serveurs futurs, afin d’éviter de nouvelles allocations.
used_servers: Nombre de serveurs utilisés.
dns_names: Nombre de noms DNS dans le cache.
dns_zones: Nombre de zones DNS en cache.
dns_queries: Nombre de requêtes DNS en cours.
dns_pending: non utilisé

MONTRER UTILISATEURS

name: Le nom d’utilisateur
pool_size: La taille de pool substituée par l’utilisateur. Peut être NULL si non définie.
reserve_pool_size: La taille de réserve personnalisée pour l’utilisateur, ou NULL si non définie.
pool_mode: Le mode de pool défini par l’utilisateur, ou NULL si non défini.
max_user_connections: Paramètre max_user_connections de l’utilisateur. Si ce paramètre n’est pas défini pour cet utilisateur spécifique, la valeur par défaut sera affichée.
current_connections: Nombre actuel de connexions au serveur que cet utilisateur a ouvert vers tous les serveurs.
max_user_client_connections: Paramètre max_user_client_connections de l’utilisateur. Si ce paramètre n’est pas défini pour cet utilisateur spécifique, la valeur par défaut sera affichée.
current_client_connections: Nombre actuel de connexions clients ouvertes par cet utilisateur vers PgBouncer.

SHOW DATABASES

name: Nom de l’entrée de base de données configurée.
host: Hôte auquel PgBouncer se connecte.
port: Port auquel PgBouncer se connecte.
base de données: Nom réel de la base de données vers laquelle PgBouncer se connecte.
force_user: Lorsque l’utilisateur est spécifié dans la chaîne de connexion, la connexion entre PgBouncer et PostgreSQL est forcée à l’utilisateur indiqué, quel que soit l’utilisateur client.
pool_size: Nombre maximal de connexions vers le serveur.
min_pool_size: Nombre minimum de connexions vers le serveur.
reserve_pool_size: Nombre maximal de connexions supplémentaires pour cette base de données.
server_lifetime: Durée maximale de vie d’une connexion serveur pour cette base de données
pool_mode: Le mode de poolage substitut de la base de données, ou NULL si le mode par défaut doit être utilisé à la place.
load_balance_hosts: L’option load_balance_hosts de la base de données si l’hôte contient une liste séparée par des virgules.
max_connections: Nombre maximal de connexions serveur autorisées pour cette base de données, tel que défini par max_db_connections, soit globalement, soit par base de données.
current_connections: Nombre actuel de connexions serveur pour cette base de données.
max_client_connections: Nombre maximal de connexions clients autorisées pour cette instance de PgBouncer, tel que défini par max_db_client_connections par base de données.
current_client_connections: Nombre actuel de connexions clients pour cette base de données.
en pause: 1 si cette base de données est actuellement en pause, sinon 0.
désactivé: 1 si cette base de données est actuellement désactivée, sinon 0.

MONTRER LES PEERS

peer_id: Identifiant de l’entrée pair configurée.
host: Hôte auquel PgBouncer se connecte.
port: Port auquel PgBouncer se connecte.
pool_size: Nombre maximal de connexions serveur pouvant être établies vers ce pair

SHOW FDS

Commande interne – affiche la liste des descripteurs de fichiers en cours d’utilisation avec leur état interne associé.

Lorsque l’utilisateur connecté porte le nom « pgbouncer », se connecte via une socket Unix et possède le même UID que le processus en cours d’exécution, les descripteurs de fichiers réels sont transmis à travers la connexion. Ce mécanisme est utilisé pour effectuer un redémarrage en ligne. Note : Cette fonctionnalité ne fonctionne pas sous Windows.

Cette commande bloque également la boucle d’événements interne, elle ne doit donc pas être utilisée pendant que PgBouncer est en cours d’utilisation.

fd: Valeur numérique du descripteur de fichier.
tâche: L’un des éléments suivants : pooler, client ou server.

utilisateur : Utilisateur de la connexion utilisant le descripteur de fichier (FD).

base de données: Base de données de la connexion utilisant le descripteur de fichier (FD).
addr: Adresse IP de la connexion utilisant le descripteur de fichier (FD), unix si un socket Unix est utilisé.
port: Port utilisé par la connexion utilisant le descripteur de fichier (FD).
annuler: Clé d’annulation pour cette connexion.
lien: descripteur de fichier correspondant au serveur/client. NULL si inactif.

SHOW SOCKETS, SHOW ACTIVE_SOCKETS

Affiche des informations de bas niveau sur les sockets ou uniquement les sockets actifs. Cela inclut les informations affichées sous SHOW CLIENTS et SHOW SERVERS, ainsi que d’autres informations de niveau plus bas.

SHOW CONFIG

Affiche les paramètres de configuration actuels, un par ligne, avec les colonnes suivantes :

clé: Nom de la variable de configuration
valeur: Valeur de configuration
default: Valeur par défaut de la configuration
modifiable: Soit yes soit no, indique si la variable peut être modifiée pendant l’exécution. Si no, la variable ne peut être modifiée qu’au démarrage. Utilisez SET pour modifier une variable en cours d’exécution.

SHOW MEM

Affiche des informations de bas niveau sur les tailles actuelles des différentes allocations mémoire internes. Les informations présentées sont sujettes à modification.

SHOW DNS_HOSTS

Afficher les noms d’hôte dans le cache DNS.

hostname: Nom d’hôte.
ttl: Nombre de secondes avant la prochaine recherche.
addrs: Liste de adresses séparées par des virgules.

SHOW DNS_ZONES

Affiche les zones DNS en mémoire cache.

zonename: Nom de la zone.
serial: Numéro de série actuel.
count: Noms d’hôtes appartenant à cette zone.

SHOW VERSION

Affiche la chaîne de version de PgBouncer.

MONTRER ÉTAT

Affiche les paramètres d’état de PgBouncer. Les états actuels sont : active, paused et suspended.

Commandes de contrôle du processus

PAUSE [db]

PgBouncer tente de se déconnecter de tous les serveurs. La déconnexion de chaque connexion serveur attend que cette connexion serveur soit libérée selon le mode de pooling du pool serveur (en mode pooling de transactions, la transaction doit être terminée ; en mode statement, l’instruction doit être terminée ; en mode pooling de sessions, le client doit se déconnecter). La commande ne retourne pas avant que toutes les connexions serveur n’aient été déconnectées. À utiliser lors d’un redémarrage de la base de données.

Si le nom de la base de données est spécifié, seule cette base de données sera mise en pause.

Les nouvelles connexions clients vers une base de données en pause resteront en attente jusqu’à l’appel de RESUME.

DÉSACTIVER db

Refuser toutes les nouvelles connexions clients sur la base de données donnée.

ACTIVER db

Autoriser de nouvelles connexions clients après une commande précédente DISABLE.

RECONNECT [db]

Ferme chaque connexion serveur ouverte pour la base de données donnée, ou pour toutes les bases de données, après sa libération (selon le mode de mise en pool), même si sa durée de vie n’est pas encore écoulée. De nouvelles connexions serveur peuvent être établies immédiatement et se connecteront selon les paramètres de taille du pool.

Cette commande est utile lorsque la configuration de connexion au serveur a changé, par exemple pour effectuer un basculement progressif vers un nouveau serveur. Elle n’est pas nécessaire lorsqu’une chaîne de connexion dans le fichier pgbouncer.ini a été modifiée et rechargée (voir RELOAD) ou lorsque la résolution DNS a changé, car dans ces cas, la commande équivalente sera exécutée automatiquement. Cette commande n’est nécessaire que si quelque chose en aval de PgBouncer route les connexions.

Après l’exécution de cette commande, une période prolongée peut s’écouler durant laquelle certaines connexions serveur sont dirigées vers une ancienne destination et d’autres vers une nouvelle destination. Cette situation n’est probablement pertinente que lors du basculement du trafic en lecture seule entre des réplicas en lecture seule, ou lors du basculement entre les nœuds d’une configuration de réplication multimaster. Si toutes les connexions doivent être redirigées simultanément, PAUSE est recommandé à la place. Pour fermer les connexions serveur sans attendre (par exemple, lors d’un basculement d’urgence plutôt que d’un basculement progressif), envisagez également KILL.

KILL [db]

Déconnecter immédiatement toutes les connexions clients et serveurs pour la base de données indiquée ou pour toutes les bases de données, en excluant la base de données d’administration.

Les nouvelles connexions clients vers une base de données arrêtée resteront en attente jusqu’à l’appel de RESUME.

KILL_CLIENT id

Tuer immédiatement la connexion client spécifiée, ainsi que toutes les connexions serveur associées à ce client. Le client à tuer est identifié par la valeur id, qui peut être obtenue à l’aide de la commande SHOW CLIENTS.

Une commande d’exemple aura une forme semblable à KILL_CLIENT 1234.

SUSPENDRE

Tous les tampons de socket sont vidés et PgBouncer cesse d’écouter les données sur ceux-ci. La commande ne retourne pas avant que tous les tampons soient vides. À utiliser lors d’un redémarrage en ligne de PgBouncer.

Les nouvelles connexions clients vers une base de données suspendue attendront jusqu’à l’appel de RESUME.

SYNTHÈSE [db]

Reprendre le travail après une commande précédente KILL, PAUSE ou SUSPEND.

ARRÊT

Le processus PgBouncer s’arrête.

SHUTDOWN WAIT_FOR_SERVERS

Arrêtez d’accepter de nouvelles connexions et effectuez l’arrêt après la libération de tous les serveurs. Cela revient essentiellement à émettre PAUSE et SHUTDOWN, sauf que cette commande arrête également l’acceptation de nouvelles connexions pendant l’attente du PAUSE, tout en déconnectant immédiatement les clients en attente d’une connexion serveur. Veuillez noter que les sockets UNIX resteront ouverts pendant l’arrêt, mais n’accepteront que les connexions à la console d’administration de PgBouncer.

SHUTDOWN WAIT_FOR_CLIENTS

Arrêtez d’accepter de nouvelles connexions et arrêtez le processus une fois que tous les clients existants se sont déconnectés. Veuillez noter que les sockets UNIX resteront ouverts pendant l’arrêt, mais n’accepteront que les connexions à la console d’administration de pgbouncer. Cette commande peut être utilisée pour effectuer un redémarrage progressif sans interruption de deux processus PgBouncer en suivant la procédure suivante :

Faites fonctionner deux ou plusieurs processus PgBouncer sur le même port en utilisant so_reuseport (configurer le peering est recommandé, mais non obligatoire). Pour obtenir une interruption nulle lors du redémarrage, redémarrez ces processus un par un, laissant ainsi les autres en cours d’exécution afin d’accepter les connexions pendant qu’un processus est redémarré.
Choisissez un processus à redémarrer en premier, appelons-le A.
Exécutez SHUTDOWN WAIT_FOR_CLIENTS (ou envoyez SIGTERM) au processus A.
Forcez tous les clients à se reconnecter. Cela peut être réalisé en attendant un certain temps jusqu’à ce que le pooler côté client provoque les reconnexions en raison de son server_idle_timeout (ou d’une configuration similaire). Sinon, si aucun pooler côté client n’est utilisé, cela peut être fait en redémarrant les clients. Une fois que tous les clients se sont reconnectés, le processus A s’arrêtera automatiquement, car aucun client ne sera plus connecté à celui-ci.
Redémarrez le processus A.
Répétez les étapes 3, 4 et 5 pour chacun des processus restants, un par un, jusqu’à ce que tous les processus aient été redémarrés.

RECHARGER

Le processus PgBouncer recharge ses fichiers de configuration et met à jour les paramètres modifiables. Cela inclut le fichier de configuration principal ainsi que les fichiers spécifiés par les paramètres auth_file et auth_hba_file.

PgBouncer détecte lors d’un rechargement du fichier de configuration que les paramètres de connexion d’une définition de base de données ont changé. Une connexion serveur existante vers la destination ancienne sera fermée lors de sa prochaine libération (selon le mode de regroupement), et les nouvelles connexions serveur utiliseront immédiatement les paramètres de connexion mis à jour.

WAIT_CLOSE [db]

Attendez que toutes les connexions serveur, pour la base de données spécifiée ou pour toutes les bases de données, aient quitté l’état “close_needed” (voir SHOW SERVERS). Cette commande peut être appelée après un RECONNECT ou un RELOAD pour attendre que le changement de configuration correspondant ait été pleinement activé, par exemple dans des scripts de basculement.

Autres commandes

SET key = arg

Modifie un paramètre de configuration (voir également SHOW CONFIG). Par exemple :

SET log_connections = 1;
SET server_check_query = 'select 2';

(Remarque : cette commande est exécutée sur la console d’administration de PgBouncer et définit les paramètres de PgBouncer. Une commande SET exécutée sur une autre base de données sera transmise au serveur PostgreSQL comme toute autre commande SQL.)

Signaux

SIGHUP: Recharger la configuration. Équivalent à exécuter la commande RELOAD sur la console d’administration.
SIGTERM: Arrêt sécurisé maximal. Attend que tous les clients actifs se déconnectent, mais n’accepte plus de nouvelles connexions. Cela équivaut à émettre la commande SHUTDOWN WAIT_FOR_CLIENTS depuis la console d’administration. Si ce signal est reçu alors qu’un arrêt est déjà en cours, un « arrêt immédiat » est déclenché à la place d’un « arrêt sécurisé maximal ». Dans les versions de PgBouncer antérieures à 1.23.0, ce signal provoquait un « arrêt immédiat ».
SIGINT: Arrêt sécurisé. Équivalent à l’envoi de SHUTDOWN WAIT_FOR_SERVERS depuis la console. Si ce signal est reçu pendant qu’un arrêt est déjà en cours, un « arrêt immédiat » est déclenché au lieu d’un « arrêt sécurisé ».
SIGQUIT: Arrêt immédiat. Équivalent à l’envoi de SHUTDOWN depuis la console d’administration.
SIGUSR1: Identique à l’envoi de PAUSE depuis la console d’administration.
SIGUSR2: Identique à l’envoi de RESUME depuis la console d’administration.

Paramètres Libevent

Du document officiel de Libevent :

Il est possible de désactiver la prise en charge d’epoll, kqueue, devpoll ou poll en définissant la variable d’environnement EVENT_NOEPOLL, EVENT_NOKQUEUE, EVENT_NODEVPOLL, EVENT_NOPOLL ou EVENT_NOSELECT, respectivement.
En définissant la variable d’environnement EVENT_SHOW_METHOD, libevent affiche la méthode de notification du noyau qu’il utilise.

Voir aussi

pgBouncer(5) - page de manuel des descriptions des paramètres de configuration

https://www.pgbouncer.org/

4 - Compilation et installation de PgBouncer

Instructions de compilation et d’installation de PgBouncer

Construction

PgBouncer dépend de quelques éléments pour être compilé :

GNU Make 3.81+
Libevent 2.0+
pkg-config
OpenSSL 1.0.1+ pour la prise en charge du TLS
(facultatif) c-ares en tant qu’alternative à evdns de Libevent
(facultatif) bibliothèques LDAP
(facultatif) bibliothèques PAM

Lorsque les dépendances sont installées, exécutez simplement :

$ ./configure --prefix=/usr/local
$ make
$ make install

Si vous compilez à partir de Git, ou si vous compilez pour Windows, veuillez consulter les instructions de compilation spécifiques ci-dessous.

Prise en charge des recherches DNS

PgBouncer effectue des recherches de noms d’hôte au moment de la connexion, et non une seule fois au moment du chargement de la configuration. Cela nécessite une implémentation DNS asynchrone. Le tableau suivant indique les backends pris en charge ainsi que leur ordre de sondage :

backend	parallel	EDNS0 (1)	/etc/hosts	SOA lookup (2)	note
c-ares	yes	yes	yes	yes	problème avec IPv6+CNAME pour les versions ≤ 1.10
evdns, libevent 2.x	yes	no	yes	no	ne vérifie pas les mises à jour de /etc/hosts
getaddrinfo_a, glibc 2.9+	yes	yes (3)	yes	no	non disponible sur les systèmes non-glibc
getaddrinfo, libc	no	yes (3)	yes	no	nécessite pthreads

EDNS0 est requis pour avoir plus de 8 adresses derrière un même nom d’hôte.
Une requête SOA est nécessaire pour vérifier à nouveau les noms d’hôte en cas de changement du numéro de série de la zone.
Pour activer EDNS0, ajoutez options edns0 à /etc/resolv.conf.

c-ares est l’implémentation la plus complète et est recommandée pour la plupart des utilisations et des paquetages binaires (si une version suffisamment récente est disponible). L’implémentation evdns intégrée à libevent convient également à de nombreuses utilisations, sous réserve des restrictions mentionnées. Les autres backends sont principalement des options héritées à l’heure actuelle et ne bénéficient plus d’un test important.

Par défaut, c-ares est utilisé s’il est détecté. Son utilisation peut être imposée avec configure --with-cares ou désactivée avec --without-cares. Si c-ares n’est pas utilisé (non trouvé ou désactivé), alors Libevent est utilisé. Spécifiez --disable-evdns pour désactiver l’utilisation de evdns de Libevent et revenir à une implémentation basée sur libc.

Authentification PAM

Pour activer l’authentification PAM, ./configure dispose d’un indicateur --with-pam (valeur par défaut : no). Lorsqu’il est compilé avec le support PAM, un nouveau type d’authentification global pam devient disponible pour valider les utilisateurs via PAM.

Authentification LDAP

Pour activer l’authentification LDAP, ./configure dispose d’un indicateur --with-ldap (valeur par défaut : no). Lorsqu’il est compilé avec le support LDAP, un nouveau type d’authentification global ldap devient disponible pour valider les utilisateurs via LDAP.

intégration systemd

Pour activer l’intégration avec systemd, utilisez l’option configure --with-systemd. Cela permet d’utiliser Type=notify (ou Type=notify-reload si vous utilisez systemd 253 ou une version ultérieure) ainsi que l’activation par socket. Consultez etc/pgbouncer.service et etc/pgbouncer.socket pour des exemples.

Construction à partir de Git

La compilation de PgBouncer à partir de Git nécessite de générer les fichiers d’en-tête et de configuration avant de pouvoir exécuter configure :

$ git clone https://github.com/pgbouncer/pgbouncer.git
$ cd pgbouncer
$ ./autogen.sh
$ ./configure
$ make
$ make install

Tous les fichiers seront installés sous /usr/local par défaut. Vous pouvez fournir une ou plusieurs options en ligne de commande à configure. Exécutez ./configure --help pour afficher les options disponibles et les variables d’environnement qui personnalisent la configuration.

Paquets supplémentaires requis : autoconf, automake, libtool, pandoc

Test

Consultez le fichier README.md dans le répertoire de test pour savoir comment exécuter les tests.

Construction sous Windows

L’environnement de compilation pris en charge sur Windows est uniquement MinGW. Cygwin et Visual $ANYTHING ne sont pas pris en charge.

Pour compiler sous MinGW, procédez comme d’habitude :

$ ./configure
$ make

Si vous effectuez une compilation croisée depuis Unix :

$ ./configure --host=i586-mingw32msvc

L’option de compilation LDAP n’est actuellement pas prise en charge sous Windows.

Exécution sous Windows

Exécution depuis la ligne de commande se déroule normalement, à l’exception des options -d (daemonize), -R (reboot) et -u (switch user) qui ne fonctionnent pas.

Pour exécuter PgBouncer en tant que service Windows, vous devez configurer le paramètre service_name afin de définir un nom pour le service. Ensuite :

$ pgbouncer -regservice config.ini

Pour désinstaller le service :

$ pgbouncer -unregservice config.ini

Pour utiliser le journal des événements Windows, définissez syslog = 1 dans le fichier de configuration. Mais avant cela, vous devez inscrire pgbevent.dll :

$ regsvr32 pgbevent.dll

Pour le désenregistrer, procédez comme suit :

$ regsvr32 /u pgbevent.dll

5 - Source Versions Téléchargement

Versions sources et paquets binaires de PgBouncer

PgBouncer 1.25

Fichier	Date	Taille	SHA256
pgbouncer-1.25.2.tar.gz	2026-05-08	865371 octets	sha256
pgbouncer-1.25.1.tar.gz	2025-12-03	864801 octets	sha256
pgbouncer-1.25.0.tar.gz	2025-11-09	863322 octets	sha256

PgBouncer 1.24

Fichier	Date	Taille	SHA256
pgbouncer-1.24.1.tar.gz	2025-04-16	717796 octets	sha256
pgbouncer-1.24.0.tar.gz	2025-01-10	706573 octets	sha256

PgBouncer 1.23

Fichier	Date	Taille	SHA256
pgbouncer-1.23.1.tar.gz	2024-08-02	700025 octets	sha256
pgbouncer-1.23.0.tar.gz	2024-07-03	694845 octets	sha256

PgBouncer 1.22

Fichier	Date	Taille	SHA256
pgbouncer-1.22.1.tar.gz	2024-03-04	677351 octets	sha256
pgbouncer-1.22.0.tar.gz	2024-01-31	670589 octets	sha256

PgBouncer 1.21

Fichier	Date	Taille	SHA256
pgbouncer-1.21.0.tar.gz	2023-10-16	668211 octets	sha256

PgBouncer 1.20

Fichier	Date	Taille	SHA256
pgbouncer-1.20.1.tar.gz	2023-08-09	638844 octets	sha256
pgbouncer-1.20.0.tar.gz	2023-07-20	638020 octets	sha256

PgBouncer 1.19

Fichier	Date	Taille	SHA256
pgbouncer-1.19.1.tar.gz	2023-05-31	623569 octets	sha256
pgbouncer-1.19.0.tar.gz	2023-05-04	616947 octets	sha256

PgBouncer 1.18

Fichier	Date	Taille	SHA256
pgbouncer-1.18.0.tar.gz	2022-12-12	600825 octets	sha256

PgBouncer 1.17

Fichier	Date	Taille	SHA256
pgbouncer-1.17.0.tar.gz	2022-03-23	598294 octets	sha256

PgBouncer 1.16

Fichier	Date	Taille	SHA256
pgbouncer-1.16.1.tar.gz	2021-11-11	591450 octets	sha256
pgbouncer-1.16.0.tar.gz	2021-08-09	592136 octets	sha256

PgBouncer 1.15

Fichier	Date	Taille	SHA256
pgbouncer-1.15.0.tar.gz	2020-11-19	588042 octets	sha256

PgBouncer 1.14

Fichier	Date	Taille	SHA256
pgbouncer-1.14.0.tar.gz	2020-06-11	578955 octets	sha256

PgBouncer 1.13

Fichier	Date	Taille	SHA256
pgbouncer-1.13.0.tar.gz	2020-04-27	574955 octets	sha256

PgBouncer 1.12

Fichier	Date	Taille	SHA256
pgbouncer-1.12.0.tar.gz	2019-10-17	567465 octets	sha256

PgBouncer 1.11

Fichier	Date	Taille	SHA256
pgbouncer-1.11.0.tar.gz	2019-08-27	571414 octets	sha256

PgBouncer 1.10

Fichier	Date	Taille	SHA256
pgbouncer-1.10.0.tar.gz	2019-07-01	480571 octets	sha256

PgBouncer 1.9

Fichier	Date	Taille	SHA256
pgbouncer-1.9.0.tar.gz	2018-08-13	469300 octets	sha256

PgBouncer 1.8

Fichier	Date	Taille	SHA256
pgbouncer-1.8.1.tar.gz	2017-12-20	465930 octets	sha256
pgbouncer-1.8.tar.gz	2017-12-19	465612 octets	sha256

PgBouncer 1.7

Fichier	Date	Taille	SHA256
pgbouncer-1.7.2.tar.gz	2016-02-26	462374 octets	sha256
pgbouncer-1.7.1.tar.gz	2016-02-18	461903 octets	sha256
pgbouncer-1.7.tar.gz	2015-12-18	459080 octets	sha256

PgBouncer 1.6

Fichier	Date	Taille	SHA256
pgbouncer-1.6.1.tar.gz	2015-09-03	431076 octets	sha256
pgbouncer-1.6.tar.gz	2015-08-01	412700 octets	sha256

PgBouncer 1.5

Fichier	Date	Taille	SHA256
pgbouncer-1.5.5.tar.gz	2015-04-09	336145 octets	sha256
pgbouncer-1.5.4.tar.gz	2012-11-28	339610 octets	sha256
pgbouncer-1.5.3.tar.gz	2012-09-12	339013 octets	sha256
pgbouncer-1.5.2.tar.gz	2012-05-29	335338 octets	sha256
pgbouncer-1.5.1.tar.gz	2012-04-17	334413 octets	sha256
pgbouncer-1.5.tar.gz	2012-01-05	411488 octets	sha256

PgBouncer 1.4

Fichier	Date	Taille	SHA256
pgbouncer-1.4.2.tgz	2011-06-16	283204 octets	sha256
pgbouncer-1.4.1.tgz	2011-04-01	282728 octets	sha256
pgbouncer-1.4.tgz	2011-01-11	231691 octets	sha256

PgBouncer 1.3

Fichier	Date	Taille	SHA256
pgbouncer-1.3.4.tgz	2010-09-09	167957 octets	sha256
pgbouncer-1.3.3.tgz	2010-05-10	167476 octets	sha256
pgbouncer-1.3.2.tgz	2010-03-15	166756 octets	sha256
pgbouncer-1.3.1.tgz	2009-07-06	161518 octets	sha256
pgbouncer-1.3.tgz	2009-02-18	160154 octets	sha256

PgBouncer 1.2

Fichier	Date	Taille	SHA256
pgbouncer-1.2.3.tgz	2008-08-08	145372 octets	sha256
pgbouncer-1.2.2.tgz	2008-08-06	145017 octets	sha256
pgbouncer-1.2.1.tgz	2008-08-04	144903 octets	sha256
pgbouncer-1.2.tgz	2008-07-29	143915 octets	sha256

PgBouncer 1.1

Fichier	Date	Taille	SHA256
pgbouncer-1.1.2.tgz	2007-12-10	122054 octets	sha256
pgbouncer-1.1.1.tgz	2007-10-26	121042 octets	sha256
pgbouncer-1.1.tgz	2007-10-09	120462 octets	sha256

PgBouncer 1.0

Fichier	Date	Taille	SHA256
pgbouncer-1.0.8.tgz	2007-06-18	93636 octets	sha256
pgbouncer-1.0.7.tgz	2007-04-19	93086 octets	sha256
pgbouncer-1.0.6.tgz	2007-04-12	92244 octets	sha256
pgbouncer-1.0.5.tgz	2007-04-11	91934 octets	sha256
pgbouncer-1.0.4.tgz	2007-04-11	91889 octets	sha256
pgbouncer-1.0.3.tgz	2007-04-11	91489 octets	sha256
pgbouncer-1.0.2.tgz	2007-03-28	90555 octets	sha256
pgbouncer-1.0.1.tgz	2007-03-15	89609 octets	sha256
pgbouncer-1.0.tgz	2007-03-13	88587 octets	sha256

Paquets binaires

Plusieurs distributions de systèmes d’exploitation proposent leur propre paquet ou port de PgBouncer. Il est donc recommandé de vérifier en premier lieu si celui-ci est déjà disponible sur votre système d’exploitation.

Versions spécifiques, pouvant inclure des versions plus récentes que celles disponibles dans les dépôts du distributeur :

RPM : yum.PostgreSQL.org
Deb : apt.PostgreSQL.org

6 - Journal des modifications

Historique des versions et notes de publication de PgBouncer

PgBouncer 1.25.x

2026-05-08 - PgBouncer 1.25.2 - “Touch humain avec une touche fraîche dans la course au titre pleine d’incertitudes

Sécurité
- Correctif CVE-2026-6664 : Une dépassement d’entier dans le code de traitement des paquets réseau de PgBouncer antérieur à la version 1.25.2 contourne une vérification de borne et peut entraîner un crash. Un attaquant distant non authentifié peut provoquer un crash de PgBouncer en envoyant un paquet d’authentification SCRAM malformé.
- Correctif CVE-2026-6665 : Le code SCRAM de PgBouncer antérieur à la version 1.25.2 ne vérifiait pas correctement la valeur de retour de strlcat() lors de la construction du contenu du message client-final SCRAM. Un serveur malveillant pouvant envoyer un message serveur-final SCRAM avec un nonce long peut déclencher un dépassement de pile.
- Correctif CVE-2026-6666 : Une référence vers un pointeur nul possible dans PgBouncer antérieur à la version 1.25.2 pouvait entraîner un crash si un serveur envoyait une réponse d’erreur sans champ SQLSTATE.
- Correctif CVE-2026-6667 : PgBouncer antérieur à la version 1.25.2 n’effectuait pas de vérification d’autorisation appropriée pour la commande KILL_CLIENT. Tous les utilisateurs ayant accès à la console d’administration, qui nécessite elle-même une authentification, pouvaient exécuter cette commande. Cette opération doit uniquement être autorisée pour les utilisateurs listés dans le paramètre admin_users.
Correctifs
- Précision de la documentation du paramètre default_pool_size.
- Correction de la documentation pour client_tls13_ciphers et server_tls13_ciphers.

2025-12-03 - PgBouncer 1.25.1 - « Correction de plusieurs bogues avant Noël »

Sécurité
- Correction de CVE-2025-12819 : avant cette version, il était possible à un attaquant non authentifié d’exécuter du SQL arbitraire pendant l’authentification en fournissant un paramètre search_path malveillant dans le message StartupMessage. Les systèmes présentant TOUS les paramètres suivants sont vulnérables :
  1. track_extra_parameters inclut search_path (configuration non par défaut, probablement configurée uniquement dans les environnements utilisant Citus ou PostgreSQL 18)
  2. auth_user est défini sur une chaîne non vide (configuration non par défaut)
  3. auth_query est configuré sans noms d’objets qualifiés (configuration par défaut, l’opérateur < n’est pas qualifié par schéma)
Correctifs
- Corrige les erreurs d’authentification SCRAM ad-hoc après une reconnexion au serveur (#1432 , introduit dans 1.25.0)
- Ajoute les typedef manquants pour les architectures exotiques sans prise en charge SIMD (#1414 , introduit dans 1.25.0)
- Supprime l’avertissement bruyant dans les journaux lorsqu’un client ferme la connexion avant d’envoyer des données (#1420 , introduit dans 1.25.0)
- Empêche une éventuelle déréférencement de pointeur nul (#1423 , introduit dans 1.25.0)
- Corrige une éventuelle fuite mémoire (#1422 , introduit dans 1.25.0)
- Corrige l’analyse SCRAM des messages du serveur (#1431 , introduit dans 1.25.0)

2025-11-09 - PgBouncer 1.25.0 - « Le version avec le support LDAP »

Fonctionnalités
- Ajouter l’authentification LDAP ! Vous pouvez la configurer à l’aide d’un fichier HBA ou à l’aide de auth_ldap_options. (#731 )
- Ajouter la prise en charge des connexions TLS côté client. Cela permet aux clients d’utiliser la mise en place plus rapide de la connexion TLS introduite dans PostgreSQL 17. PgBouncer ne peut pas (pour l’instant) se connecter aux serveurs PostgreSQL en utilisant cette mise en place plus rapide. (#1359 )
- Ajouter l’état inactif à SHOW CLIENTS. (#1191 )
- Ajouter le paramètre transaction_timeout, tant au niveau global qu’au niveau de l’utilisateur. (#1242 )
- Envoyer un message NOTICE au client s’il est mis en file d’attente sans recevoir de connexion pendant plus de 5 secondes. Cette durée peut être modifiée ou désactivée à l’aide de query_wait_notify. (#1264 )
- Ajouter le paramètre scram_iterations pour permettre aux opérateurs d’opter pour une vitesse d’authentification au détriment de la sécurité. (#1339 )
- Ajouter client_tls13_ciphers et server_tls13_ciphers pour choisir les suites de chiffrement TLSv1.3 à activer. (#1352 )
Modifications
- Améliorer considérablement les performances de l’authentification SCRAM ad hoc. (#1338 )
- Permettre à KILL de ne pas spécifier de base de données, ce qui signifie désormais KILL toutes les bases de données. (#1317 )
- La requête de vérification de santé passe par défaut à l’envoi d’une requête vide au lieu de SELECT 1. (#1233 )
- Consigner l’intégralité de la file d’attente PAM comme avertissement. Cela facilite la recherche de la cause des requêtes lentes provoquées par celle-ci. (#1297 )
- La commande RELOAD indique désormais tout erreur survenue lors du rechargement. (#1231 )
- Activer l’accès au socket UNIX de PgBouncer pendant l’arrêt pour les connexions administratives. Cela facilite pour l’opérateur de déterminer pourquoi un processus PgBouncer ne s’arrête pas et/ou d’exécuter manuellement KILL_CLIENT pour les connexions bloquées. (#1305 )
- Modifier mkauth.py pour ne plus ajouter de troisième champ obsolète. (#1365 )
- Améliorer les messages de FATAL dans les fonctions disconnect_client et disconnect_server. (#1382 )
- Arrêter l’utilisation de la fonction OpenSSL obsolète EVP_PKEY_get0_EC_KEY. Cela pourrait provoquer des problèmes avec certaines implémentations FIPS. (#1384 )
Correctifs
- Corriger la panne liée aux mots de passe longs (1024 caractères ou plus). (#1215 )
- Corriger les connexions multi-hôtes lors de l’utilisation de server_tls_sslmode=verify-full. (#1303 )
- Corriger une erreur rare FATAL lors du transfert de demandes d’annulation. (#1383 )
- Corriger le tri des paramètres dans SHOW CONFIG. (#1403 )
- Renforcer l’analyse du paquet de démarrage. (#1407 )

PgBouncer 1.24.x

2025-04-16 - PgBouncer 1.24.1 - « CVE-2025-2291 VALIDE JUSQU’À hier »

Sécurité
- Correction de CVE-2025-2291 : auparavant, PgBouncer ne tenait pas compte de la clause VALID UNTIL d’un mot de passe lors de la requête des hachages de mot de passe via son auth_query. Ainsi, si PgBouncer était utilisé comme proxy transparent devant Postgres, il pouvait autoriser des mots de passe ayant déjà expiré. Pour résoudre ce problème, la requête d’authentification par défaut ainsi que les exemples de fonctions d’authentification personnalisées dans la documentation ont été mis à jour pour prendre en compte VALID UNTIL. Si vous utilisez une auth_query personnalisée, vous devez la mettre à jour en conséquence. Si vous utilisez la requête d’authentification par défaut, vous pouvez soit mettre à jour vers PgBouncer 1.24.1, soit modifier votre configuration pour utiliser la nouvelle requête d’authentification par défaut sur une version antérieure de PgBouncer.
Correctifs
- Corrige la prise en charge de PAM en revenant à la prise en charge de l’authentification pam dans le fichier HBA. (#1291 ) (bug introduit dans la version 1.24.0)
- Corrige le bug sur la diminution du compteur de connexions utilisateur. Ce correctif était inclus dans l’étiquette 1.24.0 sur GitHub, mais le paquet de version ne le contenait pas. (#1238 ) (bug introduit dans la version 1.24.0)
- Ajoute test_load_balance_hosts.py au paquet tarball. (#1282 )
- Corrige les problèmes de tests afin de permettre leur exécution par les paquettisateurs Debian. (#1266 , #1250 )
Documentation
- Mettre à jour l’auth_query exemple pour définir un search_path sûr. (#1245 )

2025-01-10 - PgBouncer 1.24.0 - « Nouvelle année, nouveau bouncer »

Fonctionnalités
- Ajouter la prise en charge de Type=notify-reload pour systemd. Cela nécessite systemd version 253 ou ultérieure. (#1148 )
- Ajouter la commande KILL_CLIENT à la console d’administration. Cela permet de terminer une connexion client par force. (#1147 )
- Ajouter le paramètre max_user_client_connections, tant au niveau global qu’au niveau utilisateur. (#1137 )
- Ajouter le paramètre max_db_client_connections, tant au niveau global qu’au niveau base de données. (#1138 )
- Ajouter le compteur current_client_connections à la sortie de SHOW USERS et SHOW DATABASES. (#1137 , #1138 )
- Ajouter le paramètre load_balance_hosts, pour prendre en charge non le load balancing entre hôtes. (#736 )
- Exposer les compteurs d’utilisation des requêtes préparées dans SHOW STATS. (#1192 )
- Ajouter le paramètre client_idle_timeout. (#1189 )
- Ajouter au niveau utilisateur les paramètres query_timeout et reserve_pool_size. (#1180 , #1228 )
- Activer la prise en charge de l’authentification pam dans le fichier HBA. (#326 )
Changements
- Ne pas réutiliser les connexions lors d’un RELOAD si la configuration TLS est inchangée. Auparavant, si vous aviez des connexions TLS, toutes étaient réinitialisées lors d’un RELOAD, ce qui pouvait entraîner une dégradation temporaire mais importante des performances. À présent, cela n’arrive que lorsque les paramètres TLS sont réellement modifiés. (#1157 )
- Activer la prise en charge des requêtes préparées par défaut, max_prepared_statements est désormais défini à 200 par défaut. Ce changement de valeur par défaut ne devrait affecter que les clients qui utilisent réellement des requêtes préparées. Si vous utilisez des requêtes préparées, il est recommandé de consulter les limitations de cette fonctionnalité dans notre documentation . (#1144 )
- Les sockets, clients et serveurs peuvent désormais être identifiés par un ID unique dans la sortie d’administration. Auparavant, ils pouvaient être identifiés par leur pointeur, mais ces derniers étaient souvent réutilisés par de nouveaux clients après déconnexion. (#1172 )
- Message d’erreur plus clair en cas de fichier pid vide. (#1195 )
- Renvoyer l’erreur d’origine au client en cas d’échec de server_login_retry. (#1152 )
- Consigner l’erreur d’origine du serveur en cas d’erreur provenant de auth_query. (#1187 )
- Définir default_pool_size à 0 signifie une taille illimitée. (#1227 )
- Changer le nom du paramètre reserve_pool pour les bases de données en reserve_pool_size. Le nom précédent reste une alias du nouveau nom. (#1232 )
Correctifs
- Amélioration de la gestion de divers cas d’erreur peu probables, tels que les erreurs de mémoire (OOM). Ces erreurs pouvaient auparavant provoquer des plantages ou des fuites mémoire. (#1108 , #1101 , #1099 , #1169 , #1202 )
- Correction de la valeur par défaut de server_tls_sslmode dans le fichier de configuration d’exemple. (#1133 )
- Suppression de la mention dans la documentation d’un alias non valide pour server_tls_protocols. (#1155 )
- Correction d’un bogue survenant lors de l’utilisation combinée de auth_query et des connexions de réplication. Ce bogue pouvait entraîner des échecs de connexion dans de tels environnements. (#1166 )
- Ignorer les requêtes d’annulation du client pendant que PgBouncer configure les paramètres du serveur. (#298 )

PgBouncer 1.23.x

2024-08-02 - PgBouncer 1.23.1 - « Tout est remis en ordre »

Correctifs
- Corriger un éventuel plantage par segmentation après le rechargement de la configuration de PgBouncer. (#1105 ) (bug introduit dans la version 1.23.0)
- Corriger tous les plantages connus liés à put_in_order. (#1120 ) (de nouveaux plantages ont été introduits dans la version 1.23.0)
- Ajouter les fichiers manquants au fichier tar de la version qui sont nécessaires pour les tests. (#1124 ) (les fichiers manquants ont été introduits dans la version 1.23.0)

2024-07-03 - PgBouncer 1.23.0 - « Vers de nouveaux débuts »

Fonctionnalités
- Ajout du support des redémarrages progressifs. Le signal SIGTERM ne provoque plus l’arrêt immédiat du processus PgBouncer. Il effectue désormais une « fermeture très sécurisée » : il attend que tous les clients se déconnectent avant de s’arrêter. Ce nouveau comportement de SIGTERM permet les redémarrages progressifs de plusieurs processus PgBouncer derrière un équilibreur de charge, ou écoutant sur le même port à l’aide de so_reuseport. Il s’agit d’une modification mineure rétroactive. Si vous comptiez sur le comportement ancien de SIGTERM dans votre Dockerfile ou votre fichier de service Systemd, vous devez désormais utiliser SIGQUIT. (#902 )
- Ajout du support des mappages de noms d’utilisateur pour les méthodes d’authentification cert et peer. Cette fonctionnalité permet de disposer de la flexibilité selon laquelle l’utilisateur initiant la connexion n’a pas besoin d’être l’utilisateur de la base de données. Le support des mappages de noms d’utilisateur par PgBouncer fonctionne de manière très similaire à celui de PostgreSQL, avec les exceptions indiquées dans la documentation. (#996 )
- Ajout du support des connexions de réplication via PgBouncer. (#876 )
Modifications
- Améliorer la sortie de SHOW USERS pour lister les connexions. (#1040 )
- Permettre la configuration pool_size par utilisateur. (#1049 )
- Permettre la configuration server_lifetime par base de données. (#1057 )
- Ajouter le support de la liste des utilisateurs créés dynamiquement dans la sortie de SHOW USERS. (#1052 )
- Ajouter le support du type d’adresse all dans la configuration HBA. (#1078 )
- Ajouter le support du redémarrage automatique lors de l’utilisation de systemd. (#1080 )
- Augmenter le niveau minimum requis de c-ares à 1.9.0 (#1076 )
Correctifs
- Corrige les problèmes liés à la gestion des paquets de démarrage volumineux et partiels. (#1058 )
- Ajoute le support du format --config=value dans le paramètre de démarrage options. (#1064 )
- Corrige le calcul de la métrique avg_wait_time. (#727 )
- Ajoute le support de la négociation de la version du protocole postgres avec le client. (#1007 )
- Ajoute une requête en attente pour auth_query. (#1034 )
- Améliorations multiples de la documentation et de l’infrastructure CI.

PgBouncer 1.22.x

2024-03-04 - PgBouncer 1.22.1 - « Il fait l’été à Bangalore »

Correctifs
- Corrige les problèmes provoqués par certains clients utilisant des requêtes COPY FROM STDIN. Ces requêtes pouvaient entraîner des fuites mémoire, des régressions de performance et un comportement incorrect des requêtes préparées. (#1025 ) (bug introduit dans la version 1.21.0)
- Ajoute les tests manquants au fichier source de la version (#1026 ) (les tests manquants ont été introduits dans les versions 1.19.0 et 1.21.0)

2024-01-31 - PgBouncer 1.22.0 - « DEALLOCATE ALL »

Fonctionnalités
- Ajoute le support de DEALLOCATE ALL et DISCARD ALL lorsque max_prepared_statements est défini à une valeur non nulle (le mode normal DEALLOCATE reste toujours non pris en charge) (#972 )
- Permet de configurer auth_query par base de données (#979 )
Modifications
- Amélioration des paramètres dans le fichier unit systemd recommandé (#983 )
- Mise en œuvre de la logique d’échec rapide pour tous les scénarios où aucune connexion fonctionnelle à la base de données n’existe plus et aucune ne peut être établie (#998 )
- Améliorations multiples de la documentation
Correctifs
- Corrige un problème dans PG14+ où PgBouncer envoyait SET DateStyle='ISO' pour chaque transaction (#879 )
- Corrige le traitement du champ vide application_name (#999 )
- Corrige la compilation sous Windows avec OpenSSL 3.2.0 (#1009 )

PgBouncer 1.21.x

2023-10-16 - PgBouncer 1.21.0 - “Celui avec les requêtes préparées

Fonctionnalités
- Ajout du support des requêtes préparées nommées au niveau du protocole ! Il s’agit probablement de l’une des fonctionnalités les plus demandées pour PgBouncer. L’utilisation conjointe des requêtes préparées avec PgBouncer peut réduire considérablement la charge CPU de votre système (aussi bien côté PgBouncer que côté PostgreSQL). Dans des tests synthétiques, cette fonctionnalité a permis d’augmenter le débit des requêtes de 15 % à 250 %, selon la charge. Pour bénéficier de cette nouvelle fonctionnalité, vous devez modifier le paramètre max_prepared_statements afin de lui attribuer une valeur non nulle (la valeur exacte dépend de votre charge, mais 100 est probablement raisonnable). Consultez la documentation sur max_prepared_statements pour plus de détails sur le fonctionnement de cette fonctionnalité, ses limitations et la manière de régler la valeur. Une fois cela fait, assurez-vous que votre bibliothèque cliente utilise effectivement les requêtes préparées. La manière de procéder varie selon le client, vous devez donc consulter la documentation du client que vous utilisez. Cette fonctionnalité a été testée de manière très poussée avant sa mise en production, mais des problèmes de performance ou des bogues pourraient toutefois exister en raison de sa complexité. Si vous en découvrez, veuillez les signaler. (#845 )
Modifications
- Amélioration de la sécurité des paramètres OpenSSL, les valeurs par défaut étaient très obsolètes. À partir de cette version, les valeurs par défaut sont désormais identiques à celles du système OpenSSL sur lequel s’exécute PgBouncer. (#948 & libusual/#41 )
- PgBouncer utilise désormais OpenSSL pour calculer les hachages MD5 lorsque cela est possible. Cela est nécessaire pour utiliser PgBouncer de manière conforme au FIPS. (#949 )
- Conserver min_pool_size pour les pools avec un utilisateur forcé, même si aucun client n’est connecté à PgBouncer (#947 )
- La manière dont un peer_id est encodé dans le jeton d’annulation par PgBouncer a changé, ce qui signifie que la réplication entre différentes versions de PgBouncer ne fonctionnera pas si toutes ne se trouvent pas du même côté de la limite de version v1.21.0. (#945 )
Correctifs
- Correction d’un plantage avec le message d’erreur : « FATAL dans la fonction client_proto() : état client incorrect : 6/7 » (#928 ) (bug introduit dans la version 1.18.0)
- Correction d’un plantage avec le message d’erreur : « FATAL dans la fonction server_proto() : serveur dans un état incorrect : 11 » (#927 ) (bug introduit dans la version 1.18.0)
- Réduction du niveau de journalisation pour les annulations (#903 )
- Correction du préfixe de journalisation slog pour les pairs (#922 )
- Correction d’erreurs de frappe dans la documentation (#932 )
- Correction des erreurs signalées par l’analyseur statique (#943 )
- Ne pas tuer tous les clients en attente en cas d’erreurs FATAL temporaires durant la connexion (#946 )
- Utiliser la base de données automatique lorsque la base de données dans auth_dbname n’est pas explicitement configurée (#921 )
Nettoyage
- Suppression du support pour udns (#938 )

PgBouncer 1.20.x

2023-08-09 - PgBouncer 1.20.1 - « Options facultatives »

Correctifs
- Corrige une régression où placer options à l’intérieur de ignore_startup_parameters ne faisait plus ignorer les paramètres inconnus présents dans le paramètre de démarrage options depuis la version 1.20.0. (#908 )
- Corrige une coquille ambiguë dans la documentation (#917 )

2023-07-20 - PgBouncer 1.20.0 - “Un nom drôle se trouve ici

Dépréciations
- L’option de redémarrage en ligne est désormais considérée comme obsolète. Cette fonctionnalité a reçu très peu d’attention ces dernières années. Elle présente plusieurs problèmes connus, et les nouvelles fonctionnalités ajoutées ne la prennent souvent pas en charge. La méthode recommandée pour effectuer un redémarrage en ligne aujourd’hui consiste à utiliser les fonctionnalités so_reuseport et peers. Ainsi, vous pouvez faire fonctionner plusieurs processus PgBouncer sur le même port. En redémarrant ces processus un par un, vous pouvez vous assurer qu’un processus PgBouncer reste toujours en écoute sur le port souhaité. (#894 )
Fonctionnalités
- Introduit le track_extra_parameters qui permet de suivre davantage de paramètres en mode pooling de transactions. Auparavant, PgBouncer ne suivait que application_name, DateStyle, TimeZone et standard_conforming_strings. À présent, PgBouncer suit IntervalStyle par défaut. En modifiant track_extra_parameters, vous pouvez suivre encore plus de paramètres, mais uniquement ceux que PostgreSQL renvoie au client . Si vous utilisez Citus 12.0+, Citus veillera à ce que PostgreSQL renvoie également search_path au client. Ainsi, si vous utilisez Citus, vous pouvez ajouter search_path à la configuration track_extra_parameters. (#867 )
- Transmettre le SQLSTATE pendant l’étape d’authentification. Cela permet de détecter l’absence de base de données, ce qui est utilisé par Npgsql (un fournisseur de données .NET pour PostgreSQL). (#814 )
- Changer la valeur par défaut de server_tls_sslmode en prefer. (#866 )
- Ajouter la prise en charge du paramètre de démarrage options. Cela permet d’utiliser la variable d’environnement PGOPTIONS que connaissent psql et libpq . En utilisant cette variable, vous pouvez définir n’importe quel paramètre PostgreSQL au démarrage. Cela ne fonctionne que pour les paramètres PostgreSQL que PgBouncer suit via track_extra_parameters. (#878 )
Correctifs
- Ne plus planter lorsque la base pgbouncer est utilisée comme auth_dbname. Cela reste non pris en charge, mais une erreur claire est désormais affichée au lieu d’un plantage. (#817 )
- Corriger le nom de peer_cache dans SHOW MEM. Il était incorrectement affiché comme db_cache auparavant. (#864 )
- Corriger la confusion entre source et destination dans les journaux. PgBouncer enregistrait une adresse IP source alors qu’il s’agissait en réalité de l’adresse IP de destination. (#880 )
- N’enregistrer les connexions administrateur via les sockets Unix que lorsque log_connections est défini à 1. (#883 )

PgBouncer 1.19.x

2023-05-31 - PgBouncer 1.19.1 - « Sunny Spring »

Il s’agit d’une mise à jour mineure qui corrige quelques bogues récemment introduits :

Correctifs
- Correctif : FATAL dans la fonction disconnect_client() : état client incorrect : 0 (#846 ) (bug introduit dans la version 1.18.0)
- Correctif : FATAL dans la fonction server_proto() : serveur en état incorrect : 14 (#849 ) (bug introduit dans la version 1.18.0)
- Ajout des fichiers nécessaires à l’exécution des tests basés sur Python au fichier source de la version de publication (#852 ) (nouveaux tests introduits dans la version 1.19.0)

2023-05-04 - PgBouncer 1.19.0 - “Le genre classique, généré à la main

Fonctionnalités
- Ajouter l’option auth_dbname, qui précise contre quelle base de données exécuter le auth_query. (#764 )
- Ajouter la commande SHOW STATE, qui indique si PgBouncer est actif, en pause ou suspendu. (#528 )
- Ajouter le support du peering entre processus PgBouncer. Cela permet de configurer PgBouncer de manière à ce que les requêtes d’annulation fonctionnent encore lorsque plusieurs processus PgBouncer différents sont derrière un même équilibreur de charge. (#666 )
- Ajouter un paramètre dédié cancel_wait_timeout, qui détermine après combien de temps abandonner l’envoi d’une requête d’annulation. Valeur par défaut : 10 secondes. (#833 )
- Nouveau cadre de test (#792 )
Correctifs
- Correction d’une fuite mémoire possible lors d’une erreur d’établissement de connexion TLS. (#796 )
- Amélioration des messages d’erreur pour les options de ligne de commande non prises en charge sous Windows. (#620 )
- Correction de l’appel à disconnect_server sur un serveur en état BEING_CANCELED. (#815 ) (introduit dans la version 1.18.0)
- Ne plus quitter avec un statut non nul lors de la réception d’un SIGTERM. (#834 )
- Échec immédiat au démarrage lorsque la création d’une socket a échoué dans unix_socket_dir. (#830 )
- Échec immédiat au démarrage lorsque aucune des adresses dans listen_addr ne peut être écoutée. (#838 )
- Afficher davantage de messages d’avertissement avec plus d’informations lorsque sbuf_connect échoue. Cela est particulièrement utile en cas d’échec de création de sockets Unix. (#837 )
Nettoyages
- Mises à jour diverses de CI pour une meilleure performance
- Suppression d’AppVeyor

PgBouncer 1.18.x

2022-12-12 - PgBouncer 1.18.0 - « Aucun mystère de vrai »

Fonctionnalités
- Ajouter application_name à SHOW CLIENTS/SERVERS/SOCKETS sortie (#449 )
- Ajouter des informations sur les requêtes d’annulation à la sortie de SHOW CLIENTS /SERVEURS/ POOLS (#782 )
Correctifs
- Faire échouer l’opération sbuf_send_pending si le socket de destination est fermé (#652 )
- Corriger plusieurs plantages possibles (#700 , #730 )
- Corriger un dépassement dans la liste d’hôtes séparés par des virgules, qui redirigeait la connexion vers un socket Unix (#747 )
- Ne pas évincer de connexions pour atteindre min_pool_size (#648 )
- Corriger SHOW HELP avec PostgreSQL 15 (#769 )
- Corriger une condition de concurrence dans la gestion de l’annulation des requêtes. L’annulation d’une requête d’un client pouvait annuler celle d’un autre client lorsque PgBouncer recevait la demande d’annulation après que la requête visée s’était déjà terminée. (#717 )
Nettoyages
- Mises à jour diverses de CI

PgBouncer 1.17.x

2022-03-23 - PgBouncer 1.17.0 - « Une ligne a été tracée »

Fonctionnalités
- Une définition de base de données peut spécifier une liste hôte séparée par des virgules. Les hôtes seront connectés selon un schéma de rotation.
- Lorsqu’une connexion est tentée vers une base de données inexistante, l’erreur (“base de données introuvable”) est désormais signalée après l’authentification. Cela empêche les clients non authentifiés de sonder l’existence de bases de données. (Cela correspond à la modification apportée dans la version 1.15.0, qui consistait à signaler les utilisateurs manquants après l’authentification.)
- Ne pas envoyer d’erreurs de déconnexion du serveur au client avant la connexion. Cela pourrait révéler des informations non publiques, telles que des détails de configuration, à un client qui n’est pas encore connecté.
- Augmenter à nouveau la longueur maximale du mot de passe. Apparemment, la dernière augmentation n’a pas été suffisante assez longtemps.
- Supprimer le rechargement automatique de auth_file. Le auth_file n’est désormais relu que lors d’un rechargement du fichier de configuration, et non plus automatiquement dès qu’il est modifié.
- La version pour Windows inclut désormais un fichier de ressource d’information sur la version.
- Les versions pour Windows créées sur CI sont désormais liées de manière statique, ce qui permet de les utiliser directement sans dépendances supplémentaires.
Correctifs
- Le support d’OpenSSL 3 a été corrigé. Les versions précédentes plantaient.
- Ne pas appliquer le mécanisme de défaillance rapide au moment de la connexion. Ceci fait partie du changement mentionné ci-dessus qui consiste à ne pas signaler les erreurs du serveur avant l’authentification. Cela corrige également une situation particulière liée à l’authentification en pass-through SCRAM, où il est nécessaire de permettre l’échange d’authentification côté client afin de pouvoir réauthentifier côté serveur. Le mécanisme de défaillance rapide s’applique toujours juste après l’authentification, de sorte que le comportement observé reste identique dans la plupart des cas.
- Modifier auth_type dans l’exemple pgbouncer.ini par md5 afin de correspondre à la valeur par défaut intégrée. Certains utilisent ce fichier comme fichier de configuration par défaut, vérifiez donc si cette modification de configuration reste pertinente pour votre cas d’utilisation.
- Corriger le plantage à la sortie dans les builds avec assertions activées.
- Améliorer la documentation et le comportement de tcp_defer_accept. La documentation était incorrecte et trompeuse concernant la valeur par défaut. Dans certains cas, une valeur erronée était affichée par la commande “show config”. En outre, si l’option est définie mais non prise en charge, afficher une erreur au lieu de l’ignorer, de manière similaire à la gestion des options de socket spécifiques à la plateforme.
- Corriger la compilation avec c-ares sous Windows. c-ares >=1.18.0 est désormais requis sous Windows.
Nettoyages
- La plupart des avertissements de dépréciation provenant d’Autoconf >=2.70 ont été supprimés. Les versions anciennes d’Autoconf sont toujours prises en charge.
- L’utilisation de Cirrus CI a été étendue à davantage de plateformes.
- Le support de Travis CI a été supprimé.
- Mise à jour des emplacements de recherche du fichier racine CA par défaut, afin de couvrir davantage de plateformes, telles que Fedora/RHEL/CentOS.
- Les scripts Python utilisent désormais python3 par défaut. La compatibilité avec Python 2 n’est plus maintenue.
- Les scripts de la suite de tests utilisent désormais command -v à la place de which, qui est déprécié.
- Plusieurs messages d’erreur ont été reformulés afin de préciser plus clairement la commande ou le paramètre de configuration auxquels ils se rapportent.
- Les scripts de la suite de tests n’exigent plus GNU sed.
- make check fonctionne désormais sous Windows (mais pas encore la suite de tests SSL).
- Documentation indiquant que la console d’administration ne prend en charge que le protocole de requête simple, et amélioration des messages d’erreur concernant cette limitation.

PgBouncer 1.16.x

2021-11-11 - PgBouncer 1.16.1 - « Test de profondeur contre efficacité discrète »

Il s’agit d’une mise à jour mineure incluant une correction de sécurité.

Faire que PgBouncer agisse en tant que serveur rejette les données superflues après une négociation de chiffrement SSL ou GSS.

Un attaquant en position d’interception pouvant injecter des données dans la connexion TCP pourrait insérer des données en clair au début d’une session base de données supposée protégée par chiffrement. Cela pourrait être exploité pour envoyer des commandes SQL falsifiées au serveur, bien que cela ne fonctionne que si PgBouncer ne demande aucune donnée d’authentification. (Toutefois, une configuration de PgBouncer reposant sur l’authentification par certificat SSL pourrait ne pas exiger de telles données.) (CVE-2021-3935)

2021-08-09 - PgBouncer 1.16.0 - « Repoussé un jaguar »

Fonctionnalités
- Prise en charge du rechargement à chaud des paramètres TLS. Lorsque le fichier de configuration est rechargé, les paramètres TLS modifiés prennent automatiquement effet.
- Ajout de la prise en charge des sockets de domaine Unix abstraits. Préfixez le chemin d’un socket de domaine Unix par @ pour utiliser l’espace de noms abstrait. Cette fonction correspond à celle introduite dans PostgreSQL 14.
- Les longueurs maximales des mots de passe et des noms d’utilisateur ont été portées respectivement à 996 et 128. Plusieurs services cloud l’exigent.
- La taille minimale du pool peut désormais être définie par base de données, comme la taille normale du pool et celle du pool de réserve.
- Le nombre d’annulations de requêtes en attente est affiché dans SHOW POOLS.
Correctifs
- L’analyse de configuration a été renforcée en matière de gestion des erreurs dans de nombreuses situations. Là où, auparavant, une erreur pouvait être journalisée tout en permettant la poursuite du traitement, les erreurs de configuration entraînent désormais des échecs au démarrage. C’est ce qui devait toujours se produire, mais certains fragments de code ne l’ont pas correctement implémenté. Certains utilisateurs pourront constater que leurs configurations étaient erronées depuis longtemps et ne fonctionneront plus désormais.
- La gestion des annulations de requête a été corrigée. Dans certaines circonstances, les demandes d’annulation semblaient bloquées pendant une longue durée. Ce comportement ne devrait plus se produire. En fait, les demandes d’annulation peuvent désormais dépasser le nombre de connexions du pool d’un facteur deux, ce qui signifie qu’elles ne devraient plus être bloquées. (#542 , #543 )
- Le mélange d’authentification md5 et scram via HBA a été corrigé.
- La compilation avec c-ares sous Windows a été corrigée.
- Les messages redoutés « FIXME : fin de requête, mais query_start == 0 » ont été résolus. Nous savons désormais pourquoi ils se produisent, et vous ne devriez plus les voir. (#565 )
- Correction du rechargement de default_pool_size, min_pool_size et res_pool_size. Le rechargement de ces paramètres ne fonctionnait auparavant pas.
Nettoyages
- Cirrus CI est désormais utilisé à la place de Travis CI.
- Comme à l’accoutumée, de nombreux tests ont été ajoutés.
- Le message d’erreur « serveur non propre » a été clarifié. Il indique désormais « déconnexion du client pendant que le serveur n’était pas prêt » ou « déconnexion du client avant que tout n’ait été envoyé au serveur ». Le premier cas peut survenir si la connexion client est fermée alors qu’une transaction est en cours, ce qui pouvait prêter à confusion pour certains utilisateurs.
- Il n’est plus possible d’utiliser « pgbouncer » comme nom de base de données. Ce nom est réservé à la console d’administration, et son utilisation comme nom de base de données normale ne fonctionnait jamais correctement. Cette utilisation est désormais explicitement interdite.
- Les erreurs envoyées aux clients avant la fermeture de la connexion sont désormais étiquetées comme FATAL au lieu de simplement ERROR. Certaines clients étaient autrement confus. (#564 )
- Correction des avertissements du compilateur avec GCC 11. (#623 )

PgBouncer 1.15.x

2020-11-19 - PgBouncer 1.15.0 - « Ich hab noch einen Koffer in Berlin »

Fonctionnalités
- Amélioration du rapport des échecs d’authentification. Les messages d’échec d’authentification envoyés au client indiquent désormais uniquement qu’une authentification a échoué, sans fournir de détails supplémentaires. Ces détails sont disponibles dans le journal de PgBouncer. De plus, si l’utilisateur demandé n’existe pas, l’authentification est toujours traitée jusqu’à son terme et aboutit au même message d’échec générique. Cela empêche les clients d’effectuer des sondages sur l’instance PgBouncer afin d’obtenir des informations sur les noms d’utilisateurs ou d’autres éléments liés à l’authentification. Ce comportement est similaire à celui de PostgreSQL.
- Ne rien logger si le client se déconnecte immédiatement. Cela évite le spam dans les journaux lorsque des systèmes de surveillance ouvrent simplement une connexion TCP/IP sans envoyer de données avant de se déconnecter.
- Utilisation du journal systemd pour la journalisation lorsqu’il est utilisé. Lorsque nous détectons que stderr est redirigé vers le journal systemd, nous utilisons les fonctions natives de systemd pour la sortie de journalisation. Cela évite d’imprimer des horodatages et des PID en double, rendant ainsi le journal un peu plus propre. De plus, cela ajoute des métadonnées telles que le niveau de gravité aux journaux, de sorte que si le journal est transmis à syslog, les messages disposent de métadonnées utiles.
- Un sous-ensemble de la suite de tests peut désormais être exécuté sous Windows.
- SHOW CONFIG affiche désormais les valeurs par défaut des paramètres.
Correctifs
- Correction de l’option so_reuseport sous FreeBSD. Le code original de PgBouncer 1.12.0 ne fonctionnait pas réellement sous FreeBSD. (#504 )
- Correction de la compilation sur les systèmes avec des versions anciennes de systemd. Ce problème était apparu à partir de la version 1.14.0. (#505 )
- La cible du fichier makefile pour la construction des paquets binaires Windows au format zip a été corrigée.
- Les options de ligne de commande longues fonctionnent désormais également sous Windows.
- Correction du comportement du paramètre global auth_user. Le comportement précédent était ambigu et instable, car il dépendait de l’ordre des entrées dans le fichier de configuration. Ce n’est plus le cas. (#391 , #393 )
Nettoyages
- Améliorer la stabilité et la portabilité des tests.
- Moderniser le code lié à Autoconf.
- Désactiver les avertissements de dépréciation du compilateur provenant d’OpenSSL 3.0.0.

PgBouncer 1.14.x

2020-06-11 - PgBouncer 1.14.0 - “La ritrovata magia

Fonctionnalités
- Ajouter le passage en transparence de l’authentification SCRAM. Cela permet d’utiliser des secrets SCRAM chiffrés dans PgBouncer (soit dans userlist.txt, soit provenant de auth_query) pour se connecter aux serveurs.
- Ajouter le support de l’activation par socket systemd. Cela est particulièrement utile pour permettre à systemd de gérer la création des sockets domaine Unix sur les systèmes où l’accès à /var/run/postgresql est restreint.
- Ajouter le support des sockets domaine Unix sous Windows.
Nettoyages
- Ajouter un fichier de configuration plus petit, alternatif pgbouncer-minimal.ini pour les tests ou le déploiement.

PgBouncer 1.13.x

2020-04-27 - PgBouncer 1.13.0 - “Mon jeu préféré

Fonctionnalités
- Ajouter le paramètre de configuration tcp_user_timeout pour définir l’option de socket correspondante.
- client_tls_protocols et server_tls_protocols ont maintenant pour valeur par défaut secure, ce qui signifie que seuls TLS 1.2 et TLS 1.3 sont activés. Les versions plus anciennes sont toujours prises en charge, mais ne sont pas activées par défaut.
- Ajout du support des notifications de service systemd. Actuellement, cela permet d’utiliser les unités de service Type=notify. Une intégration plus poussée est prévue pour les versions futures.
Correctifs
- Correction des messages de journal sur plusieurs lignes (libusual #24 )
- Gestion des noms d’utilisateur nuls renvoyés par auth_query de manière appropriée (#340 )
Nettoyages
- Les fichiers de paquetage Debian sous debian ont été supprimés. Il est recommandé d’utiliser les paquets provenant de https://apt.postgresql.org/ .
- Nombreuses corrections et améliorations apportées au jeu de tests
- Les tests n’essaient plus d’utiliser sudo par défaut. Cette fonctionnalité peut désormais être activée explicitement en définissant la variable d’environnement USE_SUDO
- L’API libevent a été mise à jour pour utiliser les interfaces de style version 2 et ne plus utiliser les interfaces obsolètes de la version 1.

PgBouncer 1.12.x

2019-10-17 - PgBouncer 1.12.0 - « Il s’agit d’apprendre et de s’améliorer »

Cette version inclut diverses améliorations mineures et corrections.

Fonctionnalités
- Ajouter un paramètre pour activer l’option SO_REUSEPORT socket. Sur certains systèmes d’exploitation, cela permet d’exécuter plusieurs instances de PgBouncer sur le même hôte, écoutant sur le même port, avec une distribution automatique des connexions par le noyau.
- Ajouter un paramètre pour utiliser un fichier resolv.conf distinct du système d’exploitation. Cela permet de définir des serveurs DNS personnalisés et éventuellement d’autres options DNS.
- Envoyer la sortie de SHOW VERSION sous forme de ligne de résultat normale au lieu d’un message NOTICE. Cela facilite la consommation et est cohérent avec les autres commandes SHOW.
Correctifs
- Envoyer les colonnes de statistiques en tant que numeric au lieu de bigint. Cela évite que certaines bibliothèques clientes échouent sur des valeurs dépassant la plage de bigint. (#360 , #401 )
- Corriger le problème des utilisateurs PAM qui perdaient leur mot de passe. (#285 )
- Accepter les clients ayant activé le binding de canal SCRAM. Précédemment, un client prenant en charge le binding de canal (c’est-à-dire PostgreSQL 11+) pouvait échouer à se connecter à PgBouncer dans certaines situations. (PgBouncer ne prend pas en charge le binding de canal. Ce changement ne corrige que la prise en charge des clients qui le proposent.)
- Corriger la compilation avec les versions plus récentes de musl-libc (utilisée par Alpine Linux).
Nettoyages
- Ajouter la cible make check. Cela permet d’exécuter tous les tests depuis une seule commande.
- Supprimer les références à la wiki PostgreSQL. Toutes les informations sont désormais soit dans la documentation de PgBouncer, soit sur le site web.
- Supprimer le support de la version 1.x de Libevent. La version 2.x de Libevent est désormais requise. Libevent est maintenant détecté à l’aide de pkg-config.
- Corriger les avertissements du compilateur sous macOS et Windows. La compilation sur ces plates-formes ne devrait plus générer d’avertissements.
- Corriger certains avertissements provenant de scan-build LLVM.

PgBouncer 1.11.x

2019-08-27 - PgBouncer 1.11.0 - « Instinct for Greatness »

Fonctionnalités
- Ajout du support de l’authentification SCRAM pour les clients et les serveurs. Un nouveau type d’authentification scram-sha-256 est ajouté.
- Gérer auth_type=password lorsque le mot de passe stocké est au format md5, comme le ferait un serveur PostgreSQL. (#129 )
- Ajout de l’option log_stats pour désactiver l’affichage des statistiques dans le journal. (#287 )
- Ajout de la fuseau horaire aux horodatages du journal.
- Placer le PID entre crochets dans le préfixe du journal.
Correctifs
- Correction du test de configuration OpenSSL lors de l’exécution contre une version plus récente d’OpenSSL avec -Werror.
- Correction du calcul du temps d’attente avec auth_user. Cela pouvait entraîner un crash ou afficher des valeurs incorrectes pour le temps d’attente. (#393 )
- Gestion du paquet GSSENCRequest, ajouté dans PostgreSQL 12. Il ne fait rien pour l’instant, mais évite des messages d’erreur trompeurs concernant un « en-tête de paquet incorrect ».
Nettoyages
- Nombreuses améliorations du jeu de tests et plusieurs nouveaux tests ajoutés
- Correction de plusieurs avertissements du compilateur sous Windows.
- Extension de la documentation de la section [users] et ajout à l’exemple de fichier de configuration. (#330 )

PgBouncer 1.10.x

2019-07-01 - PgBouncer 1.10.0 - “Peur du monde

Fonctionnalités
- Ajouter la prise en charge de l’activation et de la désactivation du TLS 1.3. (Le TLS 1.3 était déjà pris en charge, selon la bibliothèque OpenSSL, mais les paramètres de configuration permettant de sélectionner les versions du protocole TLS sont désormais également compatibles avec cette version.)
Correctifs
- Corriger la prise en charge du TLS 1.3. Ce problème était présent avec OpenSSL 1.1.1 et 1.1.1a (mais pas avant ni après).
- Corriger une panne rare dans SHOW FDS (#311 ).
- Corriger un problème pouvant entraîner une interruption prolongée si de nombreuses demandes d’annulation arrivent (#329 ).
- Éviter le message « réponse inattendue provenant de la requête de connexion » après un rechargement de postgres (#220 ).
- Corriger le calcul de idle_transaction_timeout (#125 ). Ce bug pouvait entraîner des délais d’attente prématurés dans des situations spécifiques.
Nettoyages
- Préciser divers messages de journalisation et d’erreur.
- Corriger les problèmes détectés par Coverity (aucun n’avait d’impact significatif en pratique).
- Améliorer et documenter tous les scripts de test.
- Ajouter des commandes SHOW supplémentaires à la documentation.
- Convertir la documentation du format rst au format Markdown.
- Tous les scripts Python présents dans l’arborescence source sont désormais compatibles avec Python 3.

PgBouncer 1.9.x

2018-08-13 - PgBouncer 1.9.0 - “Chaos Survival

Fonctionnalités
- Commande RECONNECT
- Commande WAIT_CLOSE
- Fermeture rapide – Déconnecte immédiatement un serveur en mode pool de sessions si celui-ci est en “close_needed” (reconnexion).
- Ajout de la colonne close_needed dans SHOW SERVERS
Correctifs
- Éviter le double free dans parse_filename
- Éviter le déréférencement d’un pointeur NULL dans parse_line
Nettoyages
- Portage de mkauth.py vers Python 3
- Amélioration de la documentation des signaux
- Amélioration de la documentation de démarrage rapide
- Documentation de la commande SET
- Correction de la liste des logiciels requis
- Correction des avertissements -Wimplicit-fallthrough
- Ajout de la documentation manquante pour divers champs SHOW
- Documentation du comportement de reconnexion lors d’un rechargement et d’un changement DNS
- Documentation du fait que KILL nécessite RESUME par la suite
- Précision de la documentation de server_lifetime
- Corrections de fautes de frappe et de majuscules dans les messages et la documentation
- Correction de l’appel psql dans les tests
- Autres améliorations diverses de la configuration des tests

PgBouncer 1.8.x

2017-12-20 - PgBouncer 1.8.1 - “Approche par pression constante

Correctifs
- Inclure le fichier include/pam.h dans le paquet source tarball. Cela empêchait la construction du paquet tarball 1.8.

2017-12-19 - PgBouncer 1.8 - « Confiant aux commandes »

Fonctionnalités
- Prise en charge de l’authentification PAM. (Activer avec --with-pam.)
- Ajouter les champs paused et disabled à la sortie SHOW DATABASES.
- Ajouter le champ maxwait_us à la sortie SHOW POOLS.
- Ajouter les champs wait et wait_us à la sortie des commandes SHOW.
- Ajouter de nouvelles commandes SHOW STATS_TOTALS et SHOW STATS_AVERAGES.
- Suivre les requêtes et les transactions séparément dans SHOW STATS. Les champs total_requests, avg_req et avg_query ont été remplacés par de nouveaux champs.
- Ajouter wait_time à SHOW STATS.
Correctifs
- Mise à jour de libusual pour prendre en charge OpenSSL 1.1.
- Ne pas tenter d’utiliser TLS sur les sockets Unix.
- Lors de l’analyse de pg_hba.conf, poursuivre l’analyse après les lignes erronées au lieu de rejeter entièrement le fichier. (#118 )
- Plusieurs corrections supplémentaires liées à l’analyse de HBA.
- Corriger la condition de course lors de l’annulation d’une requête. (#141 )
Nettoyages
- auth_user peut désormais être défini globalement, et non seulement par base de données. (#142 )
- Définir l’encodage du client et du serveur de la console sur UTF8.

PgBouncer 1.7.x

2016-02-26 - PgBouncer 1.7.2 - « Enfin en vol »

Correctifs
- Corrige un plantage lors de la suppression d’un fichier PID obsolète. Problème introduit dans la version 1.7.1.
- Désactivez le nettoyage — cela perturbe la prise de contrôle et n’est pas utile pour les charges de production. Problème introduit dans la version 1.7.1.
- Après une prise de contrôle, attendez que le fichier PID disparaisse avant de démarrer. Une fermeture lente due au nettoyage mémoire a mis en évidence une course existante. (#113 )
Nettoyages
- Rendre la construction reproductible en supprimant la gestion de DBGVER. (#112 )
- Antimake : trier la liste de fichiers provenant de $(wildcard), les versions récentes de gmake ne trient plus automatiquement. (#111 )
- Affiche la version de libssl dans les journaux.
- deb : activer le durcissement complet.

2016-02-18 - PgBouncer 1.7.1 - « Transférer à cinq amis ou sinon »

AVERTISSEMENT : À compter de la version 1.7, server_reset_query n’est plus exécuté lorsque la base de données est en mode pool de transactions. Ce point n’avait pas été suffisamment mis en évidence dans l’annonce de la version 1.7. Si vos applications dépendent de ce comportement, utilisez server_reset_query_always pour restaurer le comportement précédent.

Sinon, le principal travail de cette version a consisté à identifier une fuite mémoire liée au TLS, qui s’est finalement révélée n’exister pas. En réalité, la bibliothèque libssl incluse dans Debian/wheezy présente une surcharge de 600 ko par connexion (sans fuite), au lieu des 20 à 30 ko attendus. À surveiller attentivement lors de l’utilisation du TLS.

Correctifs
- TLS : Renommer le mode sslmode “disabled” en “disable”, conformément à la terminologie utilisée par PostgreSQL.
- TLS : client_tls_sslmode=verify-ca/-full rejette désormais les connexions sans certificat client. (#104 )
- TLS : client_tls_sslmode=allow/require valider le certificat client s’il est envoyé. Précédemment, la validation du certificat était laissée non configurée, ce qui faisait échouer les connexions avec certificat client. (#105 )
- Corriger une fuite mémoire lors de la libération de la base de données.
- Corriger une fuite mémoire potentielle dans tls_handshake().
- Corriger la gestion de la fin de fichier dans tls_handshake().
- Corriger la taille trop petite de memset dans asn1_time_parse compat.
- Corriger la compilation sans TLS (--without-openssl). (#101 )
- Corriger divers problèmes liés à la compilation sous Windows. (#100 )
Nettoyages
- TLS : Utiliser SSL_MODE_RELEASE_BUFFERS afin de réduire l’utilisation mémoire des connexions inactives.
- Libérer la mémoire allouée à la sortie. Facilite l’exécution des vérificateurs de fuites mémoire.
- Améliorer la documentation de server_reset_query. (#110 )
- Ajouter des options TLS à la configuration exemple.

2015-12-18 - PgBouncer 1.7 - “Les couleurs varient après la résurrection

Fonctionnalités
- Prise en charge des connexions TLS. OpenSSL/LibreSSL est utilisé comme implémentation backend.
- Prise en charge de l’authentification via certificat client TLS.
- Prise en charge de l’authentification « peer » sur les sockets Unix.
- Prise en charge du fichier de contrôle d’accès basé sur l’hôte, comme pg_hba.conf dans Postgres. Cela permet de configurer le TLS pour les connexions réseau et l’authentification « peer » pour les connexions locales.
Nettoyages
- Définit query_wait_timeout à 120 s par défaut. La valeur par défaut actuelle (0) entraîne un enfilement infini, ce qui n’est pas utile. Cela signifie que si un client a une requête en attente et n’a pas été affecté à une connexion serveur, la connexion client sera fermée.
- Désactive server_reset_query_always par défaut. La réinitialisation de requête n’est désormais utilisée que dans les pools en mode session.
- Augmente pkt_buf à 4096 octets. Améliore les performances avec TLS. Le comportement est probablement spécifique à la charge, mais il est sans danger de le faire depuis la version 1.2, où les tampons de paquet sont séparés des connexions et utilisés de manière paresseuse depuis le pool.
- Prise en charge du comptage des paquets ReadyForQuery attendus en cas de pipeline. Évite de libérer le serveur trop tôt. Corrige #52 .
- Amélioration de la logique sbuf_loopcnt : la socket est garantie de être retraitée même en l’absence d’événement provenant de la socket. Nécessaire pour TLS, qui dispose de son propre mécanisme de tamponnage.
- Adaptation des tests système pour fonctionner avec les versions modernes de BSD et MacOS. (Eric Radman)
- Suppression de l’authentification crypt. Elle est obsolète et n’est plus prise en charge par PostgreSQL depuis la version 8.4.
- Correction de l’option de configuration “–with-cares” sans argument : elle était défectueuse.

PgBouncer 1.6.x

2015-09-03 - PgBouncer 1.6.1 - « Studio Audience Approves »

Fonctionnalités
- Nouveau paramètre : server_reset_query_always. Lorsqu’il est défini, désactive l’utilisation de server_reset_query dans les pools non sessionnels. PgBouncer introduit un mode de poolage par pool, mais le poolage par session et le poolage par transaction ne doivent pas utiliser la même requête de réinitialisation. En réalité, le poolage par transaction ne doit pas utiliser de requête de réinitialisation.
  It is set in 1.6.x, but will be disabled in 1.7.
Correctifs
- [SECURITÉ] Suppression de l’affectation non valide de auth_user. (#69) Lorsque auth_user est défini et que le client demande un nom d’utilisateur inexistant, le client se connecte en tant que auth_user. Ce comportement est incorrect.
  CVE-2015-6817
- Ignorer NoticeResponse dans handle_auth_response. Sinon, les niveaux de journalisation verbeux du serveur entraînent des échecs de connexion.
- console : Remplir auth_user lorsque auth_type=any. Sinon, la journalisation peut planter (#67).
- Plusieurs correctifs de portabilité (OpenBSD, Solaris, OSX).

2015-08-01 - PgBouncer 1.6 - « Zombies de l’avenir »

Fonctionnalités
- Charger le hachage du mot de passe utilisateur depuis la base de données postgres. Nouveaux paramètres :
  auth_user user to use for connecting same db and fetching user info. Can be set per-database too.
  auth_query SQL query to run under auth_user. Default: “SELECT usename, passwd FROM pg_shadow WHERE usename=$1”
  (Cody Cutrer)
- Le mode de poolage peut être configuré à la fois par base de données et par utilisateur. (Cody Cutrer)
- Limites de connexions par base de données et par utilisateur : max_db_connections et max_user_connections. (Cody Cutrer / Pavel Stehule)
- Ajouter les commandes DISABLE/ENABLE pour empêcher les nouvelles connexions. (William Grant)
- Nouveau backend DNS : c-ares. Seul backend DNS à prendre en charge toutes les fonctionnalités intéressantes : /etc/hosts avec actualisation, recherche SOA, réponses longues (via TCP/EDNS+UDP) et IPv6. Il est désormais le backend privilégié, et devrait probablement être le seul backend à l’avenir, puisqu’il est inutile de maintenir une multitude de bibliothèques insuffisantes.
  SNAFU: c-ares versions <= 1.10 have bug which breaks CNAME-s support when IPv6 has been enabled. (Fixed upstream.) As a workaround, c-ares <= 1.10 is used IPv4-only. So PgBouncer will drop other backends only when c-ares >1.10 (still unreleased) has been out some time…
- Affiche remote_pid dans SHOW CLIENTS/SERVERS. Disponible pour les clients connectés via des sockets Unix, ainsi que pour les serveurs TCP et sockets Unix. Dans le cas d’un serveur TCP, le PID est extrait de la clé d’annulation.
- Ajouter un paramètre de configuration séparé (dns_nxdomain_ttl) pour contrôler le cache négatif DNS. (Cody Cutrer)
- Ajoutez l’adresse IP et le port de l’hôte client à application_name. Cela est activé par un paramètre de configuration application_name_add_host qui est désactivé par défaut. (Andrew Dunstan)
- Les fichiers de configuration contiennent la directive ‘%include FILENAME’ pour permettre de diviser la configuration en plusieurs fichiers. (Andrew Dunstan)
Nettoyages
- log : entourer l’adresse ipv6 de crochets []
- log : lors de la connexion au serveur, afficher l’adresse IP locale et le port
- win32 : utiliser le style gnu pour les arguments longs : –foo
- Autoriser les chiffres dans le nom d’hôte, essayer toujours d’analyser avec inet_pton
- Corriger deallocate_all() dans la FAQ
- Corriger le mot-clé incorrect dans l’exemple de fichier de configuration (Magnus Hagander)
- Autoriser les commentaires (avec ‘;’) dans les fichiers d’authentification. (Guillaume Aubert)
- Corriger les fautes d’orthographe dans les messages de journalisation et les commentaires. (Dmitriy Olshevskiy)
Correctifs
- corriger le lancement de nouvelles connexions pendant la maintenance (Cody Cutrer)
- ne pas charger deux fois le fichier d’authentification au démarrage (Cody Cutrer)
- invalidation correcte pour les bases autodéfinies
- IPv6 : définir IPV6_V6ONLY sur la socket d’écoute.
- win32 : ne pas définir SO_REUSEADDR sur la socket d’écoute.
- corriger la copie d’adresse IPv6
- corriger l’annulation des clients en attente. (Mathieu Fenniak)
- petit correctif, vérifier obligatoirement le résultat de calloc (Heikki Linnakangas)
- ajouter une nouvelle ligne à la fin du fichier PID (Peter Eisentraut)
- ne pas autoriser de nouvelles connexions serveur lorsque PAUSE a été émis. (Petr Jelinek)
- corriger « paquet incorrect » lors de la connexion lorsque l’en-tête est retardé. (Michal Trojnara, Marko Kreen)
- corriger les erreurs détectées par Coverty. (Euler Taveira)
- désactiver server_idle_timeout lorsque le nombre de serveurs tombe en dessous de min_pool (#60) (Marko Kreen)

PgBouncer 1.5.x

2015-04-09 - PgBouncer 1.5.5 - « Play Dead To Win »

Correctifs
- Corrige une panne distante — un ordre de paquets non valide provoque une recherche pointeur NULL. Non exploitable, uniquement une attaque de type DDoS.

2012-11-28 - PgBouncer 1.5.4 - « Pas de fuites, apprentissage réussi »

Correctifs
- DNS : correction d’une fuite mémoire dans le backend getaddrinfo_a().
- DNS : correction d’une fuite mémoire dans le backend udns.
- DNS : correction du calcul des statistiques.
- DNS : amélioration de la gestion des messages d’erreur pour getaddrinfo_a().
- Correction de la compilation sous Win32.
- Correction de la vérification des dépendances du compilateur dans configure.
- Quelques corrections dans la documentation.

2012-09-12 - PgBouncer 1.5.3 - “Quantum Toaster

Correction critique
- Les noms de base de données trop longs peuvent entraîner un plantage, ce qui est potentiellement déclenchable à distance si les bases de données automatiques sont activées.

Les vérifications initiales supposaient que tous les noms proviennent de fichiers de configuration, ce qui justifiait l’utilisation de fatal(), mais lorsque les bases de données automatiques sont activées - par ‘*’ dans la section [databases] - le nom de la base peut provenir du réseau, ce qui rend la fermeture à distance possible.

[CVE-2012-4575](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4575)

Fonctionnalités mineures
- max_packet_size - paramètre de configuration permettant de régler la taille maximale des paquets autorisés. La valeur par défaut est conservée à (2G-1), mais elle peut désormais être réduite.
- En cas d’en-tête de paquet non analysable, l’afficher en hexadécimal dans le journal et le message d’erreur.
Correctifs
- AntiMake : il utilisait $(relpath) et $(abspath) pour manipuler les chemins, mais cela entraînait une erreur de compilation lorsque le chemin de l’arborescence source contenait des liens symboliques. Le code a maintenant été modifié pour ne plus fonctionner qu’avec des chaînes de caractères simples.
- console : il est désormais possible d’utiliser SET pour définir des valeurs de chaîne vide.
- config.txt : indique que tous les délais d’attente peuvent être définis sous forme de nombres à virgule flottante. Il s’agit d’une fonctionnalité peu visible introduite à la version 1.4.

2012-05-29 - PgBouncer 1.5.2 - « Ne mâche pas, avale simplement »

Correctifs
- En raison d’une erreur, reserve_pool_timeout était exprimé en microsecondes, au lieu de secondes, ce qui activait immédiatement la réserve lorsque le pool était plein. Cette valeur est désormais exprimée en secondes, comme prévu. (Signalé par Keyur Govande)

2012-04-17 - PgBouncer 1.5.1 - « Abandonner, Réessayer, Ignorer ? »

Fonctionnalités
- Paramètres permettant de configurer les permissions sur le socket Unix : unix_socket_mode=0777, unix_socket_group=’’
Correctifs
- Permettre une chaîne vide pour les variables côté serveur — cela est nécessaire pour assurer le bon fonctionnement de “application_name”, qui est le seul paramètre ne disposant pas de valeur par défaut côté serveur.
- En cas de modification de la chaîne de connexion, exiger une actualisation des paramètres du serveur. Précédemment, PgBouncer continuait avec les anciens paramètres, ce qui provoquait des dysfonctionnements lors d’une mise à jour de Postgres.
- En cas de modification de la chaîne de connexion autodb, fermer les anciennes connexions.
- cf_setint : utiliser strtol() au lieu de atoi() pour analyser les paramètres de configuration entiers. Cela permet de traiter les valeurs hexadécimales, octales et améliore la détection des erreurs.
- Utiliser sigqueue() pour détecter l’existence de union sigval — corrige la compilation sur HPUX.
- Supprimer la commande ‘git’ du fichier Makefile, qui provoque des erreurs aléatoires lors d’une compilation à partir d’un paquet tarball standard.
- Documenter le paramètre stats_period. Ce paramètre permet de régler la période d’affichage des statistiques.
- Exiger Asciidoc >= 8.4, les documents ne sont plus compatibles avec les versions antérieures.
- Cesser d’essayer de réessayer en cas d’EINTR provenant de close().

2012-01-05 - PgBouncer 1.5 - « Clients satisfaits depuis 2007 »

Si vous utilisez plus de 8 adresses IP derrière un même nom DNS, vous devez désormais utiliser le protocole EDNS0 pour les requêtes. Seuls les backends getaddrinfo_a()/getaddrinfo() et UDNS le supportent ; libevent 1.x/2.x ne le fait pas. Pour l’activer pour libc, ajoutez « options edns0 » à /etc/resolv.conf.

GNU Make 3.81+ est requis pour la compilation.

Fonctionnalités
- Détection des modifications des réponses DNS et invalidation des connexions vers les adresses IP désormais absentes de la dernière réponse. (Petr Jelinek)
- Invalidation basée sur le numéro de série de la zone DNS. Lorsque l’option dns_zone_check_period est définie, toutes les zones DNS sont interrogées pour obtenir leur SOA, et si le numéro de série a changé, toutes les adresses hôtes sont redemandées. Cette fonction est nécessaire pour assurer une invalidation déterministe des connexions, car l’invalidation au moment de la recherche est inutile si aucune recherche n’est effectuée. Fonctionne uniquement avec le backend UDNS nouveau.
- Nouvelles commandes SHOW DNS_HOSTS et SHOW DNS_ZONES pour examiner le cache DNS.
- Nouveau paramètre : min_pool_size — évite de supprimer toutes les connexions lorsqu’il n’y a pas de charge. (Filip Rembialkowski)
- idle_in_transaction_timeout — tue la transaction si l’attente est trop longue. Non défini par défaut.
- Nouveau backend libudns pour les requêtes DNS. Plus fonctionnel que evdns. Utiliser –with-udns pour l’activer. Ne fonctionne pas encore avec IPv6.
- Commande KILL, pour tuer immédiatement toutes les connexions d’une base de données. (Michael Tharp)
- Migration vers le système de construction Antimake pour obtenir des fichiers Makefiles plus lisibles. Une version GNU Make 3.81 ou supérieure est désormais requise pour la compilation.
Correctifs
- Le DNS fonctionne désormais avec les noms d’hôtes IPv6.
- Ne pas modifier l’état de la connexion lorsqu’un NOTIFY arrive du serveur.
- Divers correctifs de documentation. (Dan McGee)
- Console : prise en charge de la citation ident avec “”. À l’origine, aucune commande ne prenait de noms de base de données, donc aucune citation n’était nécessaire.
- Console : autorisation des chiffres au début des expressions régulières de mot. Essayer d’utiliser un parseur strict rendrait les choses trop complexes ici.
- Ne pas expirer les bases de données automatiques en pause. (Michael Tharp)
- Créer les bases de données automatiques au besoin lors de l’opération PAUSE. (Michael Tharp)
- Correction du message de journal incorrect émis par la commande RESUME. (Peter Eisentraut)
- Lorsqu’un paramètre user= est présent sans password= dans la chaîne de connexion, le mot de passe est pris dans la liste des utilisateurs.
- Analyse correcte du caractère ‘*’ dans le code de prise de contrôle.
- autogen.sh : compatibilité avec les versions anciennes d’autoconf/automake.
- Correction de la panne lors de l’exécution en tant que service sous win32 due à une mauvaise implémentation de basename() dans les bibliothèques mingw/msvc. Une version compatible de basename() est désormais toujours utilisée.

PgBouncer 1.4.x

2011-06-16 - PgBouncer 1.4.2 - Algorithme « Strike-First »

Systèmes d’exploitation concernés : *BSD, Solaris, Win32.

Correctifs de portabilité
- Passer les CFLAGS au lienur. Nécessaire lors de l’utilisation de la fonction getaddrinfo_a() basée sur pthread en fallback.
- lib/find_modules.sh : Remplacer split() par index()+substr(). Cela devrait permettre le fonctionnement avec les versions plus anciennes d’AWK.
- <usual/endian.h> : Ignorer les définitions système de htoX/Xtoh. Il se peut qu’un sous-ensemble de macros soit défini.
- <usual/signal.h> : Séparer sigval compatible de sigevent compatible
- <usual/socket.h> : Inclure <sys/uio.h> pour obtenir iovec
- <usual/time.h> : Détection améliorée des fonctions sur win32
- <usual/base_win32.h> : Supprimer la déclaration redondante de sigval/sigevent

2011-04-01 - PgBouncer 1.4.1 - « C’était tout un spectacle »

Fonctionnalités
- Prise en charge de l’écoute/connecter sur les adresses IPv6. (Hannu Krosing)
- Adresses d’écoute multiples dans ’listen_addr’. Pour chaque appel à getaddrinfo(), les noms peuvent également être utilisés.
- console : Envoyer la version de PgBouncer en tant que ‘server_version’ au client.
Correctifs importants
- Désactiver getaddrinfo_a() sur glibc < 2.9 car il provoque un plantage sur les versions anciennes.
  Notable affected OS’es: RHEL/CentOS 5.x (glibc 2.5), Ubuntu 8.04 (glibc 2.7). Also Debian/lenny (glibc 2.7) which has non-crashing getaddrinfo_a() but we have no good way to detect it.
  Please use libevent 2.x on such OS’es, fallback getaddrinfo_a() is not meant for production systems. And read new ‘DNS lookup support’ section in README to see how DNS backend is picked.
  (Hubert Depesz Lubaczewski, Dominique Hermsdorff, David Sommerseth)
- Par défaut, –enable-evdns si la bibliothèque libevent 2.x est utilisée.
- Activer tcp_keepalive par défaut, car c’est ce que fait également Postgres. (Hubert Depesz Lubaczewski)
- Définit par défaut server_reset_query sur DISCARD ALL pour assurer la compatibilité avec Postgres.
- win32 : Corriger les plantages liés à une adresse de socket Unix NULL. (Hiroshi Saito)
- Correction de l’opération de nettoyage autodb : le code de nettoyage ancien mélangait bases de données et pools : dès qu’un pool vide était détecté, la base de données était marquée comme « inactif », ce qui pouvait entraîner la fermeture d’une base de données avec des utilisateurs actifs.
  Reported-By: Hubert Depesz Lubaczewski
Correctifs
- Rendre la fonction getaddrinfo_a compatible et non bloquante en utilisant un seul thread parallèle pour les recherches.
- Activer la compilation avec pthread si getaddrinfo_a est utilisé.
- Le release_server n’a pas défini ->last_lifetime_disconnect lors de la déconnexion par durée de vie. (Emmanuel Courreges)
- win32 : corriger le fichier d’authentification avec des fins de ligne DOS – load_file() ne tenait pas compte de la réduction de taille du fichier lors du chargement. (Rich Schaaf)
- <usual/endian.h> : ajouter une détection autoconf pour les fonctions d’encodage/décodage afin d’éviter les conflits sur BSD. (James Pye)
- Ne pas planter si le fichier de configuration n’existe pas. (Lou Picciano)
- Ne pas planter en cas d’échec de recherche DNS lors de la journalisation au niveau bruit (-v -v). (Hubert Depesz Lubaczewski, Dominique Hermsdorff)
- Utiliser des accents graves au lieu de $(cmd) dans find_modules.sh pour améliorer la portabilité. (Lou Picciano)
- Utiliser ‘awk’ au lieu de ‘sed’ dans find_modules.sh pour améliorer la portabilité. (Giorgio Valoti)
- Journaliser les informations sur le backend DNS asynchrone actif au démarrage.
- Corriger –disable-evdns pour qu’il signifie « non » au lieu de « oui ».
- Préciser dans la documentation que -R nécessite unix_socket_dir.
- Discuter de server_reset_query dans faq.txt.
- Restaurer le memset perdu dans l’allocateur de tranches.
- Diverses corrections mineures de portabilité dans libusual.

2011-01-11 - PgBouncer 1.4 - “Gore Code

Fonctionnalités
- Recherche DNS asynchrone – au lieu de résoudre les noms d’hôtes au moment du rechargement, ceux-ci sont désormais résolus au moment de la connexion, avec mise en cache configurable. (Voir le paramètre dns_max_ttl.)
  By default it uses getaddrinfo_a() (glibc) as backend, if it does not exist, then getaddrinfo_a() is emulated via blocking(!) getaddrinfo().
  When –enable-evdns argument to configure, libevent’s evdns is used as backend. It is not used by default, because libevent 1.3/1.4 contain buggy implementation. Only evdns in libevent 2.0 seems OK.
- Nouvelle variable de configuration : syslog_ident, pour personnaliser le nom syslog.
- Prise en charge correcte du paramètre de démarrage application_name.
- Options longues en ligne de commande (Guillaume Lelarge)
- Correctifs de compatibilité Solaris (Hubert Depesz Lubaczewski)
- Nouvelle variable de configuration : disable_pqexec. Les environnements très paranoïaques peuvent désactiver le protocole de requête simple avec cette option. Nécessite que les applications utilisent uniquement le protocole de requête étendu.
- Compatibilité Postgres : si le nom de la base est vide dans le paquet de démarrage, utilisez le nom d’utilisateur comme base.
Correctifs
- Les paramètres serveur DateStyle et TimeZone doivent utiliser la casse exacte.
- Console : envoyer les paramètres serveur datetime, timezone et stdstr au client.
Nettoyages internes
- Utilisez la bibliothèque libusual pour les fonctions utilitaires de bas niveau.
- Supprimez la limite de longueur fixe des paramètres du serveur.

PgBouncer 1.3.x

2010-09-09 - PgBouncer 1.3.4 - « Bouncer est toujours droit »

Correctifs
- Appliquer une logique de défaillance rapide au moment de la connexion. Ainsi, si le serveur échoue, les clients reçoivent une erreur lors de la connexion.
- Ne pas étiqueter automatiquement les bases de données générées pour leur vérification au moment du rechargement, sinon elles sont supprimées, car elles n’existent pas dans la configuration.
- Ignorer par défaut le paramètre application_name. Cela évite que tous les utilisateurs de Postgres 9.0 n’aient à l’ajouter eux-mêmes dans ignore_startup_parameters=.
- Corriger la citation pg_auth. ‘' n’est pas utilisé à cet endroit.
- Meilleure signalisation d’erreurs depuis la console, afficher la requête entrante à l’utilisateur.
- Prise en charge des systèmes d’exploitation (OpenBSD) où tv_sec n’est pas de type time_t.
- Éviter les avertissements trop bruyants sous gcc 4.5.

2010-05-10 - PgBouncer 1.3.3 - “NSFW

Améliorations
- Rendre le paramètre listen(2) configurable : listen_backlog. Cela est utile sur les systèmes où la valeur maximale autorisée est configurable.
- Améliorer les messages de déconnexion pour indiquer quel utilisateur ou nom de base a provoqué l’échec de connexion.
Correctifs
- Déplacer la logique de redémarrage rapide. L’ancienne implémentation était ennuyeuse dans le cas de bases de données ou d’utilisateurs définitivement corrompus, en tentant de réessayer même lorsque aucun client ne souhaitait se connecter.
- Faire en sorte que les fonctions de journalisation conservent l’ancien errno, sinon PgBouncer peut se comporter de manière inattendue aux niveaux de journalisation élevés ou en cas de problèmes d’écriture du journal.
- Augmenter la taille de divers tampons liés au démarrage afin de gérer le démarrage plus bruyant d’EDB.
- Détecter les requêtes de démarrage au protocole V2 et fournir une raison claire pour la déconnexion.

2010-03-15 - PgBouncer 1.3.2 - « Boomerang Bullet »

Correctifs
- Nouvelle variable de configuration ‘query_wait_timeout’. Si le client ne reçoit pas de connexion au serveur dans ce délai en secondes, il sera tué.
- Si aucune connexion serveur n’est disponible dans le pool et que la dernière tentative de connexion a échoué, alors ne pas mettre les connexions clients en attente, mais envoyer une erreur immédiatement.
  This together with previous fix avoids unnecessary stalls if a database has gone down.
- Suivre l’état libevent dans sbuf.c pour éviter un appel double à event_del(). Bien qu’il soit généralement sûr, cela ne semble pas fonctionner à 100 %. Nous devrions désormais toujours savoir si l’appel a été effectué ou non.
- Désactiver la maintenance pendant SUSPEND. Sinon, avec des délais d’expiration courts, le bouncer ancien pourrait fermer quelques connexions après les avoir transférées.
- Appliquer client_login_timeout aux clients en attente du paquet d’accueil (première connexion au serveur). Sinon, ils peuvent rester en attente indéfiniment, sauf si query_timeout est défini.
- win32 : Ajouter l’option -U/-P à -regservice pour permettre à l’utilisateur de choisir le compte sous lequel exécuter le service. Le choix automatique précédent entre le compte Local Service et le compte Local System n’était pas suffisamment fiable.
- console : Supprimer le caractère \0 à la fin des colonnes texte. Il était difficile à détecter, car les clients C le géraient correctement.
- Améliorations de la documentation. (Greg Sabino Mullane)
- Préciser quelques messages de journal liés à la connexion.
- Changer le niveau de journalisation des erreurs envoyées par le pooler (généralement lors de la déconnexion) de INFO à WARNING, car elles indiquent des problèmes.
- Message du journal de changement pour query_timeout : « timeout de requête ».

2009-07-06 - PgBouncer 1.3.1 - « Conforme désormais aux exigences de surveillance de l’NSA »

Correctifs
- Corrige un problème lié à sbuf_loopcnt qui pouvait entraîner des connexions bloquées. Si la longueur de la requête ou du résultat est proche d’un multiple de (pktlen*sbuf_loopcnt) [10 k par défaut], elle pouvait rester en attente de données supplémentaires qui ne s’afficheraient jamais.
- Rend la reconfiguration de base de données immédiate. Actuellement, les anciennes connexions pouvaient être réutilisées après SIGHUP.
- Corrige SHOW DATABASES qui était cassé suite à l’ajout d’une colonne.
- L’accès à la console était désactivé lorsque “auth_type=any” car pgbouncer supprimait le nom d’utilisateur. Correction : si “auth_type=any”, autoriser tout utilisateur à accéder à la console en tant qu’administrateur.
- Corrige la mauvaise définition du macro CUSTOM_ALIGN. Heureusement, il est inutilisé si le système d’exploitation définit déjà ALIGN, aussi le bug semble n’avoir jamais eu lieu dans la pratique.
- win32 : appeler WSAStartup() toujours, pas seulement en mode démon car l’analyse de configuration doit résoudre les hôtes.
- win32 : entourer le nom de fichier de configuration de guillemets dans la ligne de commande du service pour autoriser les espaces dans les chemins. Le chemin de l’exécutable ne semble pas nécessiter cela grâce à une certaine magie win32.
- Ajoute STATS au texte de SHOW HELP.
- doc/usage.txt : les unités de temps dans les résultats de la console sont en microsecondes, pas en millisecondes.

2009-02-18 - PgBouncer 1.3 - “Nouveau coup final Ki-Smash

Fonctionnalités
- IANA a attribué le port 6432 comme port officiel pour PgBouncer. Par conséquent, le numéro de port par défaut a été modifié en 6432. Les utilisateurs individuels existants n’ont pas besoin de procéder à une modification, mais si vous distribuez des paquets de PgBouncer, veuillez modifier le port par défaut du paquet pour qu’il corresponde au port officiel.
- Création dynamique de bases de données (David Galoyan)
  Now you can define database with name “*”. If defined, it’s connect string will be used for all undefined databases. Useful mostly for test / dev environments.
- Prise en charge Windows (Hiroshi Saito)
  PgBouncer runs on Windows 2000+ now. Command line usage stays same, except it cannot run as daemon and cannot do online reboot. To run as service, define parameter service_name in config. Then:
```
> pgbouncer.exe config.ini -regservice
> net start SERVICE_NAME
```
  To stop and unregister:
```
> net stop SERVICE_NAME
> pgbouncer.exe config.ini -unregservice
```
  To use Windows Event Log, event DLL needs to be registered first:
```
> regsrv32 pgbevent.dll
```
  Afterwards you can set “syslog = 1” in config.
Fonctionnalités mineures
- Les noms de bases de données dans le fichier de configuration peuvent désormais être entre guillemets à l’aide de la syntaxe standard SQL d’identification, afin de permettre l’utilisation de caractères non standards dans les noms de bases.
- Nouveaux paramètres ajustables : ‘reserve_pool_size’ et ‘reserve_pool_timeout’. En cas de clients dans le pool ayant attendu plus de ‘reserve_pool_timeout’ secondes, ‘reserve_pool_size’ indique le nombre de connexions pouvant être ajoutées au pool. Il peut également être défini par pool à l’aide de la variable de connexion ‘reserve_pool’.
- Nouvelle option réglable ‘sbuf_loopcnt’ pour limiter le temps passé sur une socket.
  In some situations - eg SMP server, local Postgres and fast network - pgbouncer can run recv()->send() loop many times without blocking on either side. But that means other connections will stall for a long time. To make processing more fair, limit the times of doing recv()->send() one socket. If count reaches limit, just proceed processing other sockets. The processing for that socket will resume on next event loop.
  Thanks to Alexander Schocke for report and testing.
- L’authentification crypt() est désormais facultative, puisqu’elle a été supprimée de Postgres. Si le système d’exploitation ne la fournit pas, PgBouncer fonctionne correctement sans elle.
- Ajoutez des millisecondes aux horodatages de journalisation.
- Remplacer l’implémentation MD5 ancienne par une version plus compacte.
- Mettre à jour la licence ISC avec la clarification de la FSF.
Correctifs
- En cas d’échec de event_del(), procédez simplement au nettoyage. Auparavant, PgBouncer tentait de le réessayer si l’échec était dû à ENOMEM. Mais cela a provoqué des inondations de logs avec des répétitions infinies, si bien que libevent ne semble pas le supporter.
  Why event_del() report failure first time is still mystery.
- –enable-debug ne contrôle désormais plus que le retrait des informations de débogage du binaire. Il n’interagit plus avec -fomit-frame-pointer car cela est dangereux.
- Corrige l’ordre d’inclusion, car sinon les fichiers d’inclusion système pourraient être chargés avant les fichiers internes. Ce problème affectait le fichier d’en-tête md5.h récent.
- Inclure le fichier COPYRIGHT dans le .tgz…

PgBouncer 1.2.x

2008-08-08 - PgBouncer 1.2.3 - « Bytes soigneusement sélectionnés »

Correctifs
- Désactive le code SO_ACCEPTFILTER pour les BSDs qui ne fonctionnaient pas.
- Inclut l’exemple etc/userlist.txt dans le fichier tgz.
- Utilise ‘$(MAKE)’ au lieu de ‘make’ pour la récursion (Jorgen Austvik).
- Définit _GNU_SOURCE car glibc est inutilisable autrement.
- Permet à libevent 1.1 de passer le test de liaison afin que nous puissions plus tard indiquer « 1.3b+ requis ».
- Détecte les fichiers PID obsolètes et les supprime.

Merci à Devrim GUNDUZ et à Bjoern Metzdorf pour leurs rapports de problèmes et leurs tests.

2008-08-06 - PgBouncer 1.2.2 - « Barf-bag inclus »

Correctifs
- Supprimez ‘drop_on_error’, cela était une mauvaise idée. Il a été ajouté comme solution de contournement pour un comportement défectueux du cache de plan dans Postgres, mais peut entraîner des dommages dans le cas courant où certaines requêtes renvoient toujours une erreur.

2008-08-04 - PgBouncer 1.2.1 - « Waterproof »

Fonctionnalités
- Nouveau paramètre ‘drop_on_error’ – si le serveur génère une erreur, la connexion ne sera pas réutilisée mais supprimée après que le client l’ait terminée. Cela est nécessaire pour actualiser le cache des plans. L’actualisation automatique ne fonctionne pas même dans la version 8.3. Valeur par défaut : 1.
Correctifs
- COMMANDE SHOW SOCKETS/CLIENTS/SERVERS : ne plus planter si la socket n’a pas de tampon.
- Correction de la boucle infinie lors de SUSPEND si suspend_timeout est déclenché.
Nettoyages mineurs
- Utilisation de <sys/uio.h> pour ‘struct iovec’.
- Annuler l’arrêt (provenant de SIGINT) lors de RESUME/SIGUSR2, sinon il sera déclenché lors du prochain PAUSE.
- Message de journalisation correct si une opération de console est annulée.

2008-07-29 - PgBouncer 1.2 - « Flûte magique ordinaire »

PgBouncer 1.2 nécessite désormais la bibliothèque libevent version 1.3b ou ultérieure. Les versions anciennes de libevent plantent avec le nouveau code de redémarrage.

Fonctionnalités
- Option de ligne de commande (-u) et paramètre de configuration (user=) pour prendre en charge le changement d’utilisateur au démarrage. pgbouncer refuse désormais de s’exécuter en tant qu’utilisateur root.
  (Jacob Coby)
- Texte d’utilisation plus descriptif (-h). (Jacob Coby)
- Nouvelle option de base de données : connect_query permettant d’exécuter une requête sur les nouvelles connexions avant qu’elles ne soient utilisées.
  (Teodor Sigaev)
- Nouvelle variable de configuration ‘ignore_startup_parameters’ permettant d’autoriser ou d’ignorer des paramètres supplémentaires dans le paquet de démarrage. Par défaut, seuls les paramètres « database » et « user » sont autorisés ; tous les autres provoquent une erreur. Cette fonctionnalité est nécessaire pour tolérer les comportements excessivement ambitieux de JDBC, qui tente de définir inconditionnellement « extra_float_digits=2 » dans le paquet de démarrage.
- Journalisation vers syslog : nouveaux paramètres syslog=0/1 et syslog_facility=daemon/user/local0.
- Redémarrage en ligne moins effrayant (-R)
  - Déplacer le chargement des descripteurs avant le fork, afin qu’il s’affiche dans la console et puisse être interrompu par ^C
  - Conserver SHUTDOWN après fork, afin que ^C soit sécurisé
  - Une tentative de connexion à la socket Unix est effectuée afin de vérifier si un processus écoute déjà. À présent, -R peut être utilisé même si aucun processus précédent n’était en cours d’exécution. Si un processus précédent existe, mais que -R n’est pas utilisé, le démarrage échoue.
- Nouvelles commandes de la console :
  - SHOW TOTALS affiche un résumé des statistiques (tel qu’il apparaît dans les journaux) ainsi que l’utilisation mémoire.
  - SHOW ACTIVE_SOCKETS - comme show sockets ; mais filtre uniquement les connexions actives.
Fonctionnalités moins visibles
- suspend_timeout - fermer les connexions bloquées et les connexions longues en cours de connexion. Cela ajoute une sécurité supplémentaire lors d’un redémarrage.
- Lorsqu’une base de données distante génère une erreur lors de la connexion, avertir les clients.
- Supprimer une base de données de la configuration et recharger le fichier fonctionne : toutes les connexions sont interrompues et la base de données est supprimée.
- Faux des paramètres dans les commandes SHOW/SET de la console pour qu’elles ressemblent davantage à celles de Postgres. C’était nécessaire pour permettre à psycopg de se connecter à la console. (client_encoding/isolation_transaction_par défaut/datestyle/timezone)
- Définir server_lifetime=0 pour déconnecter immédiatement la connexion au serveur après sa première utilisation. Une valeur « 0 » précédemment signifiait que PgBouncer ignorait l’âge du serveur. Comme ce comportement n’était pas documenté, il ne devrait pas y avoir d’utilisateurs qui en dépendent.
- Améliorations internes :
  - Les tampons de paquets sont alloués de manière paresseuse et réutilisés. Cela devrait entraîner une réduction importante de l’utilisation mémoire. Cela permet également de raisonnablement utiliser un grand pktbuf avec un grand nombre de connexions.
  - Nombreuses améliorations de gestion des erreurs ; PgBouncer devrait désormais survivre aux situations de manque de mémoire (OOM) de manière correcte.
  - Utiliser l’allocateur de tranches pour la gestion de la mémoire.
  - Nombreux nettoyages de code.
Correctifs
- Un seul appel à accept() était effectué par boucle d’événements, ce qui pouvait entraîner une file d’attente de connexions en cas d’importantes tentatives de connexion. Le socket d’écoute est désormais toujours entièrement vidé, ce qui devrait résoudre ce problème.
- Gérer EINTR provenant de connect().
- Assurer la compatibilité de configure.ac avec autoconf 2.59.
- Correctifs de compatibilité pour Solaris (Magne Maehre)

PgBouncer 1.1.x

2007-12-10 - PgBouncer 1.1.2 - “The Hammer

Fonctionnalités
- Les déconnexions dues à server_lifetime sont désormais espacées de (server_lifetime / pool_size) secondes. Cela empêche PgBouncer de provoquer des tempêtes de reconnexion.
Correctifs
- Problèmes liés à la mise à jour en ligne de la version 1.0 vers la 1.1 :
  - La version 1.0 ne suit pas les paramètres serveur, qui restent donc à NULL, mais la version 1.1 ne s’attendait pas à cette situation et plantait.
  - Si les paramètres serveur sont inconnus, mais que ceux du client sont définis, émettre une commande SET pour ces derniers, plutôt que de générer une erreur.
- Suppression des instructions de débogage temporaires qui avaient été accidentellement laissées dans le code au niveau INFO, afin d’éviter qu’elles ne polluent les journaux.
- Réparation du fichier debian/changelog
Nettoyage
- Réorganisation des champs de la structure SBuf pour obtenir un meilleur alignement du tampon.

2007-10-26 - PgBouncer 1.1.1 - “Breakdancing Bee

Correctifs
- Le paramètre serveur cache pouvait rester non initialisé, ce qui entraînait un SET inutile. Cela provoquait un problème sur la version 8.1, qui ne permet pas de modifier standard_conforming_strings. (Merci à Dimitri Fontaine pour le rapport et les tests.)
- Quelques corrections dans la documentation.
- Inclure doc/fixman.py dans le fichier .tgz.

2007-10-09 - PgBouncer 1.1 - “Mad-Hat Toolbox

Fonctionnalités
- Suivez les paramètres de serveur suivants :
```
client_encoding  datestyle, timezone, standard_conforming_strings
```
- Améliorations de la chaîne de connexion à la base de données :
  - Accepter le nom d’hôte dans host=
  - Accepter un emplacement personnalisé de socket Unix dans host=
  - Accepter les valeurs entre guillemets : password=’ asd’‘foo’
- Nouvelle variable de configuration : server_reset_query, envoyée immédiatement après la libération.
- Nouvelle variable de configuration : server_round_robin, pour basculer entre LIFO et RR.
- Le paquet d’annulation envoyé pour une connexion inactif ne la supprime plus.
- L’annulation avec ^C depuis psql fonctionne pour SUSPEND / PAUSE.
- Afficher les limites de descripteurs de fichiers au démarrage.
- Lors de la suspension, tenter d’atteindre une frontière de paquet dès que possible.
- Ajouter ’timezone’ aux paramètres de base de données.
- Utiliser un descripteur de fichier de journal longévité. Réouvert en cas de SIGHUP / RELOAD ;
- Informations sur le point de terminaison local des connexions dans SHOW SERVERS/CLIENTS/SOCKETS.
Nettoyage du code
- Plus de messages de journalisation détaillés incluent des informations sur les sockets.
- Suppression du nombre magique et nettoyage des messages d’erreur. (David Fetter)
- Structure d’enveloppe pour les informations sur le paquet courant. Élimine une grande partie de la complexité.
Correctifs
- Détecter mieux les en-têtes de paquets invalides.
- La vérification des modifications du fichier d’authentification était défectueuse, ce qui poussait PgBouncer à le recharger trop souvent.

PgBouncer 1.0.x

2007-06-18 - PgBouncer 1.0.8 - « Jutsu de pelle zombie »

Correctifs
- Correction d’un plantage lors du traitement du paquet d’annulation. (^C depuis psql)
Fonctionnalités
- PAUSE ; RESUME ; fonctionne désormais.
- Nettoyage de l’analyse des commandes de la console d’administration.
- Désactivation de la vérification coûteuse de type in-list.

2007-04-19 - PgBouncer 1.0.7 - « With Vitamin A-Z »

Correctifs
- Plusieurs paquets d’erreur/avis avec send() bloquant entre des assertions déclenchées. Corriger en supprimant entièrement la logique de vidage. Comme pgbouncer ne fait aucun tamponnage actif, cette logique n’est pas nécessaire. Il s’agissait d’un vestige de l’époque où le tamponnage était transféré au noyau via MSG_MORE.
- Éviter également d’appeler la logique recv() lorsque l’envoi est débloqué.
- Code de recherche dans la liste pour admin_users et stats_users traitait incorrectement les recherches partielles. Correction apportée.
- Uniformiser la recherche de l’UID du pair sur les sockets UNIX avec getpeereid().

2007-04-12 - PgBouncer 1.0.6 - « Daily Dose »

Correctifs
- Le correctif « Désactiver la maintenance pendant la prise de contrôle » pouvait désactiver la maintenance de manière globale. Corriger cela.
- Correctif de compilation pour FreeBSD, <sys/ucred.h> nécessite <sys/param.h>. Merci à Robert Gogolok pour le signalement.

2007-04-11 - PgBouncer 1.0.5 - « Enough for today »

Correctifs
- Correction des bugs liés au redémarrage en ligne :
  - Définir -> prêt pour les serveurs inactifs.
  - Suppression du code obsolète dans use_client_socket()
  - Désactivation de la maintenance pendant la prise de contrôle.

2007-04-11 - PgBouncer 1.0.4 - « Dernier bogue « last » »

Correctifs
- Avertissement provenant d’un serveur inactif marqué comme sale. release_server() ne s’y attendait pas. Corrigez-le en les supprimant.

2007-04-11 - PgBouncer 1.0.3 - « Fearless Fork »

Correctifs
- Un traitement d’erreur manquait dans le chemin de connexion, ce qui pouvait déclencher des assertions lors de la fermeture d’une connexion.
- Nettoyage des assertions dans sbuf.c afin de détecter les problèmes plus tôt.
- Générer un fichier core lorsque Assert() est déclenché.
Nouvelles fonctionnalités
- Nouvelles variables de configuration : log_connections, log_disconnections, log_pooler_errors pour activer/désactiver le bruit d’audit.
- Variable de configuration : client_login_timeout pour tuer les connexions inactives pendant la phase d’authentification qui pourraient bloquer SUSPEND et donc le redémarrage en ligne.

2007-03-28 - PgBouncer 1.0.2 - « Supersonic Spoon »

Correctifs
- libevent peut signaler un événement supprimé à l’intérieur de la même boucle. Éviter la réutilisation du socket pour une même boucle.
- release_server() appelé depuis disconnect_client() ne vérifiait pas si le paquet avait effectivement été envoyé.

2007-03-15 - PgBouncer 1.0.1 - « Technologie alien »

Correctifs
- Utilisation mixte du temps mis en cache et du temps non mis en cache, ainsi que l’utilisation non signée du type typedef usec_t provoquait des erreurs de timeout de requête erronées.
- Correction d’un cas rare où une socket réveillée depuis un état d’attente d’envoi pouvait rester bloquée.
- File d’attente des connexions serveur plus équitable. Avant, une nouvelle requête pouvait obtenir une connexion serveur avant une requête plus ancienne.
- Retarder la libération du serveur jusqu’à ce que tout soit garanti comme envoyé.
Fonctionnalités
- Commande SHOW SOCKETS pour obtenir des informations détaillées sur l’état.
- Inclure le pointeur PgSocket dans les journaux, afin de faciliter le suivi d’une connexion.
- Dans la console, autoriser SELECT à la place de SHOW.
- Diverses nettoyages de code.

2007-03-13 - PgBouncer 1.0 - “Tuunitud bemm

Première version publique.

7 - Communauté

Ressources communautaires, tutoriels et support pour PgBouncer

Tutoriels

Comment configurer PgBouncer pour Postgres Plus Standard Server

Vue d’ensemble complète des concepts de PgBouncer.

À quoi sert le rebondissement ?

Explique les différences entre les modes de regroupement.

Prise en charge

8 - Questions fréquemment posées

Questions fréquentes sur PgBouncer

Comment se connecter à PgBouncer ?

PgBouncer agit comme un serveur Postgres, il suffit donc de configurer votre client pour qu’il se connecte au port de PgBouncer.

Comment équilibrer la charge des requêtes entre plusieurs serveurs ?

PgBouncer ne dispose pas de configuration interne multi-hôtes. Il est possible via des outils externes :

Round-robin DNS. Utilisez plusieurs adresses IP derrière un même nom DNS. PgBouncer ne résout pas le DNS à chaque nouvelle connexion. Il met en cache toutes les adresses IP et effectue le round-robin de manière interne. Note : si plus de 8 adresses IP sont associées à un même nom, le serveur DNS backend doit prendre en charge le protocole EDNS0. Voir le fichier README pour plus de détails.
Utilisez un équilibreur de charge de connexion TCP. Soit LVS ou HAProxy semble être un choix pertinent. Du côté de PgBouncer, il peut être judicieux de réduire server_lifetime et d’activer server_round_robin : par défaut, les connexions inactives sont réutilisées selon un algorithme LIFO, ce qui peut fonctionner moins bien lorsqu’un équilibrage de charge est requis.

Comment effectuer un basculement

PgBouncer ne dispose pas de configuration interne ni de détection de basculement automatique. Il est possible d’utiliser des outils externes :

Réconfiguration DNS : lorsque l’adresse IP derrière un nom DNS est modifiée, PgBouncer se reconnecte au nouveau serveur. Ce comportement peut être ajusté à l’aide de deux paramètres de configuration : dns_max_ttl détermine la durée de vie d’un nom d’hôte, et dns_zone_check_period détermine la fréquence à laquelle une zone SOA sera interrogée pour détecter des modifications. Si un enregistrement SOA de zone a changé, PgBouncer interroge à nouveau tous les noms d’hôte de cette zone.
Écrivez un nouvel hôte dans la configuration et laissez PgBouncer la recharger : envoyez le signal SIGHUP ou utilisez la commande RELOAD sur la console. PgBouncer détectera une modification de la configuration d’hôte et se reconnectera au nouveau serveur.
Utilisez la commande RECONNECT. Cette commande est destinée aux situations où aucune des deux options précédentes n’est applicable, par exemple lorsque vous utilisez HAProxy, tel que mentionné, pour acheminer les connexions vers le bas depuis PgBouncer. RECONNECT provoque simplement la réouverture de toutes les connexions vers les serveurs. Exécutez-la après que l’autre composant a modifié ses informations de routage des connexions.

Comment utiliser les requêtes préparées avec le pooling de sessions ?

En mode pooling de sessions, la requête de réinitialisation doit supprimer les instructions préparées anciennes. Cela peut être réalisé en server_reset_query = DISCARD ALL; ou, au minimum, en DEALLOCATE ALL;

Comment utiliser les requêtes préparées avec le pooling de transactions ?

Depuis la version 1.21.0, PgBouncer peut suivre les requêtes préparées en mode pool de transaction et s’assurer qu’elles sont préparées en temps réel sur la connexion serveur liée. Pour activer cette fonctionnalité, max_prepared_statements doit être défini à une valeur non nulle. Pour plus de détails, consultez la documentation de max_prepared_statements .

Si vous utilisez PHP/PDO, selon sa version, il se peut qu’il soit incompatible avec la prise en charge des requêtes préparées de PgBouncer (#991 ). PHP/PDO est uniquement compatible lorsque PHP 8.4+ et libpq 17 sont utilisés. Pour les configurations avec des versions plus anciennes, il est recommandé de procéder à une mise à jour, ou de désactiver les requêtes préparées côté client.

Désactivation des requêtes préparées dans JDBC

La manière correcte de procéder pour JDBC consiste à ajouter le paramètre prepareThreshold=0 à la chaîne de connexion.

Désactivation des requêtes préparées dans PHP/PDO

Pour désactiver l’utilisation des requêtes préparées côté serveur, l’attribut PDO PDO::ATTR_EMULATE_PREPARES doit être défini à true. Cela peut être fait au moment de la connexion :

$db = new PDO("dsn", "user", "pass", array(PDO::ATTR_EMULATE_PREPARES => true));

ou ultérieurement :

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

Comment mettre à jour PgBouncer sans interrompre les connexions ?

Vous pouvez effectuer un redémarrage progressif en suivant la procédure décrite dans la section des documents pour SHUTDOWN WAIT_FOR_CLIENTS

Comment savoir quel client est connecté à quelle connexion serveur ?

Utilisez les commandes SHOW CLIENTS et SHOW SERVERS depuis la console d’administration.

Utilisez ptr et link pour mapper la connexion client locale à la connexion serveur.
Utilisez addr et port de la connexion client pour identifier la connexion TCP depuis le client.
Utilisez local_addr et local_port pour identifier la connexion TCP au serveur.

Faut-il installer PgBouncer sur le serveur web ou le serveur de base de données ?

Cela dépend.

Installer PgBouncer sur le serveur web est pertinent lorsque des connexions de courte durée sont utilisées. Cela permet de minimiser la latence d’établissement de connexion. (Le protocole TCP nécessite plusieurs allers-retours de paquets avant qu’une connexion ne devienne utilisable.) Installer PgBouncer sur le serveur de base de données est pertinent lorsque de nombreux hôtes différents (par exemple, des serveurs web) se connectent à celui-ci. Les connexions peuvent alors être optimisées conjointement.

Il est également possible d’installer PgBouncer sur le serveur web et le serveur de base de données. Un inconvénient de cette approche est qu’une connexion PgBouncer supplémentaire ajoute une légère latence à chaque requête.

En fin de compte, vous devrez tester quel modèle convient le mieux à vos besoins en performance. Vous devriez également tenir compte de l’impact de l’installation de PgBouncer sur la bascule d’application en cas de défaillance d’un serveur web ou d’un serveur de base de données.