Documentation PgBouncer 1.26.0

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

1 - Fonctionnalités

• 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, elle est remise dans le pool. Ce mode est incompatible avec certaines fonctionnalités de PostgreSQL liées à la session. Il ne peut être utilisé que si l’application évite ces fonctionnalités, répertoriées dans le tableau ci-dessous.

  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. Ce mode vise à imposer le fonctionnement en « autocommit » côté client et s’adresse principalement à PL/Proxy.

• Faibles besoins en mémoire (2 kB par connexion par défaut), car PgBouncer n’a pas besoin de lire chaque paquet en entier d’un seul coup.

• 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 à chaud pour la plupart des paramètres.

• Prise en charge des redémarrages et mises à niveau progressifs à l’aide de plusieurs processus avec so_reuseport . L’ancien redémarrage en ligne (-R) a été supprimé dans la version 1.26.0.

Carte des fonctionnalités SQL pour les modes de pooling

Le tableau suivant répertorie plusieurs fonctionnalités de PostgreSQL et leur compatibilité avec les modes de pooling de PgBouncer. Le pooling de transactions modifie par conception le comportement du serveur attendu par le client. Il ne peut donc être utilisé que si l’application évite les fonctionnalités incompatibles.

2 - Configuration : pgbouncer.ini

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

logfile

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

pidfile

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

Par défaut : non défini

listen_addr

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

listen_port

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

Par défaut : 6432

unix_socket_dir

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).

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

unix_socket_mode

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.

Par défaut : 0777

unix_socket_group

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

user

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

pool_mode

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 s’étendant sur plusieurs instructions sont interdites dans 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 devront peut-être également être augmentées. Notez que le nombre de descripteurs de fichiers potentiellement utilisés 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éciale à cet effet. Cela signifie toutefois que vous devriez fixer le nombre de descripteurs de fichiers à un nombre suffisamment élevé pour être en 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.

Par défaut : 100

default_pool_size

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é.

Par défaut : 20

min_pool_size

Ajoute des connexions serveur supplémentaires au pool si leur 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 plafonnée à la taille du pool.

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

• l’entrée dans la section [databases] 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é)

reserve_pool_size

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

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

reserve_pool_timeout

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_db_connections

N’autorisez pas plus de ce nombre de connexions serveur par base de données (quel 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 que, lorsque la limite est atteinte, 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_db_client_connections

N’autorisez pas plus de ce nombre de connexions clients à PgBouncer par base de données (quel 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 devrait ê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 (quel 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].

Notez que, lorsque la limite est atteinte, 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_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 devrait ê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.

Par défaut : 0

track_extra_parameters

Par défaut, PgBouncer suit tous les paramètres que Postgres signale au client et qui peuvent être modifiés par le client :

• application_name
• client_encoding
• DateStyle
• default_transaction_read_only
• IntervalStyle
• scram_iterations (depuis la version 16 de PostgreSQL)
• search_path (depuis la version 18 de PostgreSQL)
• session_authorization
• standard_conforming_strings
• TimeZone

Pour permettre 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, some_extension.setting, other_extension.setting)

Note : La plupart des paramètres ne peuvent pas être entièrement suivis de cette manière. PgBouncer n’a connaissance des modifications effectuées avec SET que pour les paramètres que Postgres signale au client. Postgres dispose d’une liste officielle des paramètres qu’il signale au client . Les extensions Postgres peuvent toutefois modifier cette liste : elles peuvent ajouter elles-mêmes des paramètres qu’elles signalent également, et commencer à signaler des paramètres existants que Postgres ne signale pas. En particulier, Citus 12.0+ fait que Postgres signale aussi search_path. Certains des paramètres suivis par défaut ne sont également signalés que par les versions plus récentes de Postgres : default_transaction_read_only depuis Postgres 14, scram_iterations depuis Postgres 16 et search_path depuis Postgres 18.

Pour un paramètre suivi que Postgres ne signale pas (par exemple search_path sur les versions de Postgres antérieures à 18), PgBouncer ne connaît que la valeur qu’un client a spécifiée dans son paquet de démarrage (ou dans le paramètre de démarrage options). Cette valeur est appliquée à la connexion serveur chaque fois que le client devient actif, et le paramètre est réinitialisé à sa valeur par défaut pour les clients qui ne l’ont pas spécifié. Les modifications effectuées avec SET après la connexion ne sont pas suivies pour ces paramètres, et fuient donc vers les autres clients partageant la connexion serveur, sauf si server_reset_query_always est utilisé.

Le protocole Postgres permet de spécifier des paramètres, soit directement comme 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 : vide

ignore_startup_parameters

Par défaut, PgBouncer autorise uniquement les paramètres qu’il peut suivre dans les paquets de démarrage (voir track_extra_parameters pour la liste). 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 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 ignore_startup_parameters, auquel cas tout paramètre inconnu contenu dans options est ignoré.

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.

Par défaut : 0

disable_pqexec

Désactive 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. Le désactiver peut améliorer la sécurité. Évidemment, cela signifie que seuls les clients utilisant exclusivement le protocole Extended Query resteront fonctionnels.

Par défaut : 0

application_name_add_host

Ajoute l’adresse et le port de l’hôte client au nom d’application défini au début de la connexion. Cela permet d’identifier la source de requêtes incorrectes, etc. Cette logique s’applique uniquement au début d’une connexion. Si application_name est modifié ultérieurement avec SET, PgBouncer ne le modifie pas à nouveau.

Par défaut : 0

conffile

Affiche l’emplacement du fichier de configuration actuel. Le modifier amène PgBouncer à utiliser un autre fichier de configuration pour le prochain RELOAD / SIGHUP.

Par défaut : fichier fourni en ligne de commande

service_name

Utilisé lors de l’enregistrement du service win32.

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]

Par défaut : 60

max_prepared_statements

Lorsque cette valeur est différente de zéro, PgBouncer suit les commandes liées aux requêtes préparées nommées au niveau du protocole envoyées par le client en mode pooling de transactions et pooling d’instructions. PgBouncer garantit que toute requête préparée par un client est disponible sur la connexion serveur qui lui est attribuée, même si elle a été initialement préparée sur une autre connexion serveur.

PgBouncer examine en interne 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 de requêtes 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 requêtes préparées est désactivé pour le pooling de transactions et le pooling d’instructions. Pour obtenir les meilleures performances, vous devez veiller à ce que cette valeur soit supérieure au nombre de requêtes 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 de requêtes 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. Cette limite n’est toutefois souvent pas atteinte ; cela ne se produit que lorsque les requêtes contenues dans vos requêtes préparées ont une taille comprise entre 2 et 4 fois celle 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. Car 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 requête 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.

Par défaut : 200

scram_iterations

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.

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.

auth_type

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 haché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 permet à n’importe quel utilisateur de se connecter en tant qu’utilisateur de statistiques ; les utilisateurs listés dans admin_users reçoivent les privilèges d’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 le 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

auth_ident_file

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

auth_file

Nom du fichier à charger pour les noms d’utilisateurs 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 auth_file ou auth_user soit défini ; 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.

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.

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.

La requête doit retourner deux colonnes, le nom d’utilisateur et le mot de passe (chiffré/haché de manière appropriée). Pour signaler que l’utilisateur n’existe pas, retournez soit aucune ligne, soit une ligne dont la valeur du nom d’utilisateur est NULL. (La requête par défaut ci-dessous ne retourne aucune ligne pour un utilisateur inexistant. La variante avec la valeur NULL est utile lorsque la requête appelle une fonction retournant un enregistrement, comme dans l’exemple présenté dans la section Exemples ci-dessous.) Une valeur NULL dans la colonne du mot de passe signifie que l’utilisateur existe mais qu’aucun mot de passe n’est disponible pour lui, de sorte qu’aucun mot de passe proposé par le client ne sera accepté.

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 [databases] à 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

syslog

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

Par défaut : 0

syslog_ident

Sous quel nom envoyer les journaux à syslog.

Par défaut : pgbouncer (nom du programme)

syslog_facility

Sous quelle facility envoyer les journaux à syslog. Possibilités : auth, authpriv, daemon, user, local0-7.

Par défaut : daemon

log_connections

Enregistrer les connexions réussies.

Par défaut : 1

log_disconnections

Journaliser les déconnexions avec leurs raisons.

Par défaut : 1

log_pooler_errors

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

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.

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.

Par défaut : 0

Contrôle d’accès à la console

admin_users

Liste séparée par des virgules d’utilisateurs de base de données autorisés à se connecter et à exécuter toutes les commandes sur la console d’administration. Avec auth_type=any, cette liste détermine toujours qui reçoit les privilèges d’administrateur ; les autres utilisateurs peuvent se connecter en tant qu’utilisateurs de statistiques. Voir les contrôles d’accès à la console de la version 1.26.0 .

Par défaut : vide

stats_users

Liste séparée par des virgules d’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.

Par défaut : vide

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

server_reset_query

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 casse pas lorsqu’un certain état est conservé.

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

Par défaut : DISCARD ALL

server_reset_query_always

Indique si server_reset_query doit être exécuté dans tous les modes de pooling. Lorsque ce paramètre est désactivé (valeur par défaut), server_reset_query ne sera exécuté que dans les pools en mode pooling de sessions. Les connexions en mode pooling 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 pooling de transactions. Il transforme une panne aléatoire en une panne déterministe : les clients perdent toujours leur état après chaque transaction.

Par défaut : 0

server_check_delay

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 la valeur est une chaîne vide, 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.

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 de longue durée 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 ne sera perdue, car les transactions en cours ne sont pas interrompues, uniquement les sessions inactives.

Par défaut : 0

server_lifetime

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 inactive 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 l’authentification ne se terminent pas dans ce délai, la connexion sera fermée. [secondes]

Par défaut : 15.0

server_login_retry

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 à terminer sa connexion dans ce délai, il sera déconnecté. [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

pool_idle_timeout

Si un pool (un couple base de données/utilisateur spécifique) est resté sans connexion client ni connexion serveur pendant ce nombre de secondes, il est libéré. Ce paramètre est similaire à autodb_idle_timeout, mais il libère des pools individuels plutôt que des bases de données créées automatiquement dans leur ensemble. Notez que, contrairement à server_idle_timeout (qui ferme les connexions serveur inactives mais conserve le pool), ce paramètre libère le pool tout entier, et seulement lorsqu’il est complètement vide.

Comme pour autodb_idle_timeout, l’inconvénient est que les statistiques d’un pool libéré sont perdues. Étant donné que les totaux par base de données dans SHOW STATS correspondent à la somme des pools existant actuellement, libérer un pool fait diminuer ces totaux, ce que les systèmes de surveillance peuvent interpréter à tort comme une réinitialisation de compteur. Pour cette raison, ce paramètre est désactivé par défaut. 0 désactive. [secondes]

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

dns_max_ttl

Durée pendant laquelle les résolutions DNS peuvent être mises en cache. Le TTL DNS réel 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

dns_zone_check_period

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 (option configure --with-cares).

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

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.

Par défaut : 5

login_notify_message

Message de notification de bienvenue envoyé au client après une connexion réussie. Peut être utilisé pour s’assurer que les clients comprennent qu’ils se connectent à pgbouncer plutôt qu’à postgres directement.

Par défaut : vide (aucun message de bienvenue envoyé)

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 de fichier seront utilisés pour les nouvelles connexions après un RELOAD. 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 (ASAP), il est conseillé d’exécuter RECONNECT après le RELOAD.

La modification d’un paramètre TLS quelconque déclenche automatiquement un 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

Chiffrements 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.

Par défaut : default

client_tls13_ciphers

Chiffrements 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.

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

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)

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 : Se comporte comme prefer : demande d’abord TLS, puis se rabat sur une connexion TCP non chiffrée si le serveur refuse TLS. Le certificat du serveur n’est pas validé.
• 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

server_tls_key_file

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

Chiffrements 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 server_tls13_ciphers ci-dessous.

Par défaut : default

server_tls13_ciphers

Chiffrements 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 server_tls_ciphers.

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 ne devrait être utilisée qu’avec un statement_timeout côté serveur légèrement plus petit, 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 des serveurs ne répondant plus de s’accaparer des connexions. Il est également utile lorsque le serveur est hors service ou refuse les connexions pour quelque raison que ce soit.

Ce paramètre peut également être configuré par base de données et par utilisateur. La précédence est : utilisateur, puis base de données, puis global. Une valeur 0 explicite au niveau sélectionné désactive ce délai d’expiration. Voir le code de sélection du délai de la version 1.26.0 .

Par défaut : 120.0

cancel_wait_timeout

Temps maximal autorisé aux demandes d’annulation pour attendre leur exécution. Si la demande d’annulation 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 demandes d’annulation seront mises en file d’attente indéfiniment. [secondes]

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

Par défaut : 10.0

client_idle_timeout

Les connexions clients inactives depuis plus de ce nombre de secondes sont fermées. Cette valeur devrait ê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 que cette durée 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 que cette durée dans l’état « en transaction », il sera déconnecté. [secondes]

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

Paramètres réseau de bas niveau

pkt_buf

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.

Par défaut : 4096

max_packet_size

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.

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.

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.

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 devriez configurer le peering PgBouncer 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 le peering et so_reuseport est également disponible dans la section d’exemples de cette documentation.

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.

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.

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.

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 les caractères _0-9A-Za-z sans guillemets. Les noms contenant d’autres caractères doivent être cités avec les guillemets standard SQL pour les identifiants : 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 la surcharge)

* = host=foo

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

bar = host=foo dbname=bar

existait (en tirant parti du fait que la valeur par défaut de dbname est le nom de la base de données 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.

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

host

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 cache pendant la durée spécifiée par le 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 pooling), 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 round-robin.

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 round-robin. (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 signifie dans libpq.) 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

Par défaut : 5432

user

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.

password

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.

pool_size

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.

min_pool_size

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 [databases] a une valeur définie pour la clé user (appelée utilisateur forcé)
• il y a au moins un client connecté au pool

reserve_pool_size

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.

connect_query

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.

pool_mode

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é.

query_wait_timeout

Temps maximal autorisé aux requêtes pour attendre leur exécution. La valeur 0 désactive cette fonctionnalité. Omettez ce paramètre pour hériter de la valeur par défaut applicable. [secondes]

Voir la description du paramètre global query_wait_timeout pour plus de détails.

Un query_wait_timeout défini au niveau utilisateur prime sur ce paramètre de base de données. Si aucun des deux n’est défini, le query_wait_timeout global 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’une chaîne 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.

Par défaut : round-robin

max_db_connections

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_db_client_connections

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

server_lifetime

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

Demande un client_encoding spécifique au serveur.

datestyle

Demande le datestyle spécifique au serveur.

timezone

Demande 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 fera comme si l’utilisateur existait et ne renverra pas de message « no such user » au client, mais il n’acceptera aucun mot de passe fourni.

pool_size

Définir la taille maximale des pools pour toutes les connexions de cet utilisateur. Si ce paramètre n’est pas défini, la base de données ou default_pool_size est utilisée.

reserve_pool_size

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

pool_mode

Définir le mode de pool à utiliser pour toutes les connexions de cet utilisateur. Si ce paramètre n’est pas 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.

query_wait_timeout

Temps maximal autorisé aux requêtes pour attendre leur exécution. La valeur 0 désactive cette fonctionnalité. Omettez ce paramètre pour hériter de la valeur par défaut applicable. [secondes]

Voir la description du paramètre global query_wait_timeout pour plus de détails.

Ce paramètre prime à la fois sur le query_wait_timeout défini au niveau de la base de données et sur le global. S’il n’est pas défini, le paramètre de la base de données est utilisé, à défaut la valeur globale.

idle_transaction_timeout

Définissez le nombre maximum de secondes pendant lesquelles une transaction inactive 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.

client_idle_timeout

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 qui a reçu la requête à annuler. 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 cet 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, le peer_id de chaque processus PgBouncer doit être unique au sein du groupe. La section [peers] devrait contenir une entrée pour chacun de ces identifiants. Un exemple est disponible dans la section Exemples de cette documentation. Il est autorisé, mais non obligatoire, d’inclure dans la section [peers] le peer_id du processus PgBouncer auquel la configuration est destinée. Cette entrée sera ignorée, mais sa présence simplifie la gestion des configurations : elle permet d’utiliser exactement la même section [peers] dans plusieurs configurations.

Note 2 : Le peering 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.

host

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 cache pendant la durée spécifiée par le paramètre dns_max_ttl. Si DNS retourne plusieurs résultats, ils sont utilisés de manière round-robin. 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).

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é.

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

pool_size

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 affiché dans la section QUERY 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 d’enregistrement 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, mais à 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.
• Aucune prise en charge de 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 peering 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 : commande pgbouncer

Synopsis

pgbouncer [-d][-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

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 pendant laquelle le client reste connecté. 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 dans 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.

Depuis la version 1.26.0, PgBouncer envoie aux clients, à la connexion, les valeurs ParameterStatus pgbouncer.version, pgbouncer.pool_mode et pgbouncer.max_prepared_statements. Les pilotes peuvent utiliser ces valeurs pour détecter PgBouncer et adapter leur comportement. Le paramètre optionnel login_notify_message envoie un message NOTICE de bienvenue après une connexion réussie.

Démarrage rapide

La configuration et l’utilisation de base se déroulent comme suit.

1. 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
   

2. Créez un fichier userlist.txt contenant les utilisateurs autorisés :

    "someuser" "same_password_as_in_server"
   

3. Lancez pgbouncer :

    $ pgbouncer -d pgbouncer.ini
   

4. 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
   

5. 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|POOLS|CLIENTS|SERVERS|SOCKETS|LISTS|VERSION|...]
      SET key = arg
      RELOAD
      PAUSE
      RESUME
      SHUTDOWN
      [...]
   

6. 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.

En mode démon, la définition de pidfile ainsi que de logfile ou de syslog est requise. Aucun message de journal ne sera écrit sur stderr après le passage en arrière-plan.

Note : Ne fonctionne pas sous Windows ; pgbouncer doit y être exécuté en tant que service.

-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

Afficher la version.

-h, --help

Afficher 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. (Sauf lorsque 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 si le client possède le même UID d’utilisateur Unix que le 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.

Commandes d’affichage

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

SHOW STATS

Affiche les statistiques. Dans cette commande et les commandes apparentées, les valeurs totales sont mesurées depuis le démarrage du processus, et les moyennes sont mises à jour à chaque stats_period.

database

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, soit inactif en transaction, soit en exécution de requêtes.

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. Ne s’applique que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.

total_server_parse_count

Nombre total de requêtes préparées créées par pgbouncer sur un serveur. Ne s’applique que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.

total_bind_count

Nombre total de requêtes préparées mises en état d’exécution par les clients et transmises à PostgreSQL par pgbouncer. Ne s’applique que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.

total_client_login_count

Nombre total de connexions client réussies.

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

Nombre moyen d’octets reçus (des 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 par seconde. Ne s’applique 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 par seconde. Ne s’applique 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 mises en état d’exécution par les clients et transmises à PostgreSQL par pgbouncer par seconde. Ne s’applique que dans le mode de suivi des requêtes préparées nommées, voir max_prepared_statements.

avg_client_login_count

Nombre moyen de connexions client réussies par seconde.

SHOW STATS_TOTALS

Affiche les statistiques cumulées par base de données correspondant aux champs total_ de SHOW STATS. Les noms des colonnes renvoyées ne portent pas le préfixe total_ : la colonne total_query_count s’appelle ici query_count, par exemple.

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 SERVERS

type

S, pour serveur.

user

Nom d’utilisateur que pgbouncer utilise pour se connecter au serveur.

database

Nom de la base de données.

replication

Si la connexion serveur utilise la réplication. Peut être none, logical ou physical.

state

État de la connexion serveur de 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 de la connexion 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.

link

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.

prepared_statements

Le nombre de requêtes préparées présentes sur le serveur. Ce nombre est limité par le paramètre max_prepared_statements.

id

ID unique du serveur.

SHOW CLIENTS

type

C, pour client.

user

Utilisateur du client connecté.

database

Nom de la base de données.

replication

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 bout 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.

link

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).

database

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 exécutant actuellement 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 pooling 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é.

peer_id

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.

SHOW LISTS

Affiche les listes internes suivantes et le nombre de leurs éléments. Chaque liste occupe une ligne, avec les colonnes list et items :

databases

Nombre de bases de données.

users

Nombre d’utilisateurs.

peers

Nombre de pairs configurés.

pools

Nombre de pools.

peer_pools

Nombre de pools de pairs.

free_clients

Nombre de clients libres. Ce sont des clients déconnectés, mais PgBouncer conserve la mémoire qui leur a été allouée afin qu’elle puisse être réutilisée pour de futurs clients et é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 la mémoire qui leur a été allouée afin qu’elle puisse être réutilisée pour de futurs serveurs et éviter des 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é

SHOW USERS

name

Le nom d’utilisateur

pool_size

La valeur de remplacement de pool_size définie par l’utilisateur, ou une chaîne vide si elle n’est pas définie.

reserve_pool_size

La valeur de remplacement de reserve_pool_size définie par l’utilisateur, ou une chaîne vide si elle n’est pas définie.

pool_mode

Le mode de pooling de remplacement 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 serveur ouvertes par cet utilisateur 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.

database

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 pooling de remplacement 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 base de données. Il est défini par le paramètre max_db_client_connections de la base de données ou, si celui-ci n’est pas défini, par sa valeur globale par défaut.

current_client_connections

Nombre actuel de connexions clients pour cette base de données.

paused

1 si cette base de données est actuellement en pause, sinon 0.

disabled

1 si cette base de données est actuellement désactivée, sinon 0.

SHOW 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 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 :

key

Nom de la variable de configuration

value

Valeur de configuration

default

Valeur par défaut de la configuration

changeable

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

Affiche les noms d’hôte présents dans le cache DNS.

hostname

Nom d’hôte.

ttl

Nombre de secondes avant la prochaine recherche.

addrs

Liste d’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.

SHOW STATE

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

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 pooling d’instructions, l’instruction doit être terminée ; et 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.

DISABLE db

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

ENABLE 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 pooling), 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 ayant subi un KILL attendront 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.

RESUME [db]

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

SHUTDOWN

Le processus PgBouncer se terminera.

SHUTDOWN WAIT_FOR_SERVERS

Arrête d’accepter de nouvelles connexions et effectue l’arrêt après la libération de tous les serveurs. Cela revient essentiellement à émettre PAUSE et SHUTDOWN, sauf que cette commande cesse également d’accepter 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ête d’accepter de nouvelles connexions et arrête 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 :

1. 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é.
2. Choisissez un processus à redémarrer en premier, appelons-le A.
3. Exécutez SHUTDOWN WAIT_FOR_CLIENTS (ou envoyez SIGTERM) sur le processus A.
4. 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.
5. Redémarrez le processus A.
6. 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.

RELOAD

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 lorsqu’un rechargement du fichier de configuration modifie les paramètres de connexion d’une définition de base de données. Une connexion serveur existante vers l’ancienne destination sera fermée lors de sa prochaine libération (selon le mode de pooling), et les nouvelles connexions serveur utiliseront immédiatement les paramètres de connexion mis à jour.

WAIT_CLOSE [db]

Attend que toutes les connexions serveur, de la base de données spécifiée ou de 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 très sécurisé. Attend que tous les clients existants 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 très sécurisé ». 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

Tiré de la documentation de Libevent :

Il est possible de désactiver la prise en charge d’epoll, kqueue, devpoll, poll ou select 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

Construction

PgBouncer peut être compilé avec le système de compilation basé sur Autoconf ou avec le système Meson , plus récent mais encore expérimental. Pour l’instant, Autoconf reste le choix recommandé pour les compilations de production et la création de paquets. La compilation avec Meson devrait devenir le mode par défaut et celle avec Autoconf être supprimée dans une version future ; la tester et signaler tout problème est donc très bienvenu. La compilation dépend de quelques éléments :

• Libevent 2.0+
• pkg-config
• OpenSSL 1.0.1+ pour la prise en charge du TLS
• un compilateur C compatible C11
• (facultatif) c-ares en tant qu’alternative à evdns de Libevent
• (facultatif) bibliothèques LDAP
• (facultatif) bibliothèques PAM

La compilation avec Meson nécessite en outre Meson 0.58+ et Ninja ; la compilation avec Autoconf nécessite GNU Make 3.81+.

Lorsque les dépendances sont installées, compilez avec Autoconf :

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

ou avec Meson (expérimental) :

$ meson setup build --prefix=/usr/local
$ meson compile -C build
$ meson install -C build

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 :

1. EDNS0 est requis pour avoir plus de 8 adresses derrière un même nom d’hôte.
2. 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.
3. 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 à l’heure actuelle pour l’essentiel des options héritées et ne font plus l’objet de nombreux tests.

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

Fonctionnalités optionnelles

Les fonctionnalités PAM, LDAP et systemd sont détectées automatiquement par meson : leurs options -Dpam, -Dldap et -Dsystemd ont la valeur par défaut auto, chacune est donc compilée lorsque ses bibliothèques sont présentes. Forcez l’activation d’une fonctionnalité avec -D<feature>=enabled ou sa désactivation avec -D<feature>=disabled. La compilation Autoconf ne les détecte pas automatiquement ; activez-les explicitement avec --with-pam, --with-ldap ou --with-systemd.

Authentification PAM

Lorsqu’il est compilé avec la prise en charge de PAM, un nouveau type d’authentification global pam devient disponible pour valider les utilisateurs via PAM.

Authentification LDAP

Lorsqu’il est compilé avec la prise en charge de LDAP, un nouveau type d’authentification global ldap devient disponible pour valider les utilisateurs via LDAP.

Intégration systemd

La prise en charge de systemd 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 Autoconf nécessite de générer les fichiers d’en-tête et de configuration avant de pouvoir exécuter configure :

$ git clone --branch pgbouncer_1_26_0 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 la liste des options disponibles et des variables d’environnement qui personnalisent la configuration.

Paquets supplémentaires requis pour la compilation Autoconf à partir de Git : autoconf, automake, libtool, pandoc

Avec la compilation Meson, vous pouvez compiler directement à partir d’un checkout ; pandoc est requis pour générer les pages de manuel :

$ meson setup build
$ meson compile -C build
$ meson install -C build

Exécutez meson configure build pour afficher la liste des options -D disponibles.

Test

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

Construction sous Windows

Le seul environnement de compilation pris en charge sous Windows est MinGW. Cygwin et Visual $ANYTHING ne sont pas pris en charge.

Pour compiler sous MinGW, procédez à la compilation Autoconf habituelle :

$ ./configure
$ make

ou à la compilation Meson expérimentale :

$ meson setup build
$ meson compile -C build

En cas de compilation croisée depuis Unix avec Autoconf :

$ ./configure --host=i586-mingw32msvc

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

Exécution sous Windows

L’exécution depuis la ligne de commande se déroule comme d’habitude, à l’exception des options -d (lancement en démon) et -u (changement d’utilisateur) 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 - Téléchargement des versions sources

PgBouncer 1.26

PgBouncer 1.25

PgBouncer 1.24

PgBouncer 1.23

PgBouncer 1.22

PgBouncer 1.21

PgBouncer 1.20

PgBouncer 1.19

PgBouncer 1.18

PgBouncer 1.17

PgBouncer 1.16

PgBouncer 1.15

PgBouncer 1.14

PgBouncer 1.13

PgBouncer 1.12

PgBouncer 1.11

PgBouncer 1.10

PgBouncer 1.9

PgBouncer 1.8

PgBouncer 1.7

PgBouncer 1.6

PgBouncer 1.5

PgBouncer 1.4

PgBouncer 1.3

PgBouncer 1.2

PgBouncer 1.1

PgBouncer 1.0

Paquets binaires

Plusieurs distributions de systèmes d’exploitation proposent leur propre paquet ou port de PgBouncer. Il peut donc être judicieux de vérifier d’abord s’il est déjà disponible sur votre système d’exploitation.

Builds dédiés, pouvant inclure des versions plus récentes que celles disponibles dans les dépôts des distributeurs :

• RPM : yum.postgresql.org
• Deb : apt.postgresql.org

6 - Journal des modifications

PgBouncer 1.26.x

2026-09-23 - PgBouncer 1.26.0 - « Ignorer tous les search_path précédents »

• Sécurité
  • Correctif CVE-2026-19888 : PgBouncer antérieur à la version 1.26.0 ne vérifiait pas que le message client-final SCRAM contenait un nonce. Un attaquant distant non authentifié pouvait faire planter PgBouncer en envoyant un message client-final sans nonce. Cela s’applique également aux utilisateurs qui n’existent pas, car PgBouncer exécute pour eux un échange SCRAM simulé. Ce bogue existe depuis l’ajout de la prise en charge de SCRAM dans PgBouncer 1.11.0.
  • Correctif CVE-2026-6668 : Un dépassement d’entier dans la logique de croissance du tampon de paquets de PgBouncer antérieur à la version 1.26.0 pouvait laisser PgBouncer bloqué dans une boucle infinie. Cela nécessitait l’envoi d’une grande quantité de données dans un seul tampon de paquets, ce qui est possible sans s’être authentifié au préalable lorsque max_packet_size est laissé à sa valeur par défaut. Comme PgBouncer est mono-thread, ce blocage l’empêchait de servir le moindre client jusqu’à ce que le processus soit tué.
  • Correctif CVE-2026-6669 : PgBouncer antérieur à la version 1.26.0 ne limitait pas le nombre d’itérations SCRAM qu’il acceptait d’un serveur. Un serveur PostgreSQL malveillant ou compromis pouvait amener PgBouncer à effectuer une quantité de travail illimitée pendant une seule connexion, l’empêchant pendant ce temps de servir tous les autres clients et bases de données. Le nombre d’itérations doit désormais être au maximum de 1000000.
• Fonctionnalités
  • Suivre tous les paramètres que PostgreSQL rapporte par défaut. Cela signifie notamment que search_path (sur PostgreSQL 18 et versions supérieures) et default_transaction_read_only (sur PostgreSQL 14 et versions supérieures) sont désormais suivis par défaut. Auparavant, un client exécutant SET search_path ou SET default_transaction_read_only = true en mode pooling de transactions pouvait affecter d’autres clients qui utilisaient ensuite la même connexion serveur. (#1580 , #1573 )
  • Ajouter le paramètre pool_idle_timeout pour nettoyer les pools qui n’ont pas été utilisés depuis un certain temps. Cela est utile dans les configurations comptant de nombreux utilisateurs différents qui se connectent rarement. Sans ce paramètre activé, le nombre de pools croît sans limite dans de telles configurations. Ce paramètre est désactivé par défaut, car la suppression d’un pool fait aussi perdre ses statistiques. (#1491 )
  • Permettre de configurer query_wait_timeout par utilisateur et par base de données. (#1449 )
  • Ajouter la statistique client_login_count à SHOW STATS, qui compte les connexions client réussies. Cela permet de détecter les clients qui renouvellent sans cesse leurs connexions. (#1457 )
  • Envoyer aux clients des messages ParameterStatus spécifiques à PgBouncer à la connexion : pgbouncer.version, pgbouncer.pool_mode et pgbouncer.max_prepared_statements. Cela permet aux clients et aux pilotes de détecter qu’ils sont connectés via PgBouncer et d’adapter leur comportement en conséquence. (#1490 )
  • Ajouter le paramètre login_notify_message. Lorsqu’il est défini, sa valeur est envoyée aux clients sous forme de message NOTICE après leur connexion. Cela peut servir à indiquer clairement aux clients qu’ils sont connectés via PgBouncer et non directement à PostgreSQL. (#1488 )
  • Ajouter la prise en charge de la compilation de PgBouncer avec meson, y compris une compilation Windows utilisant l’environnement UCRT64. Les compilations Autoconf restent prises en charge. (#1524 , #1426 , #1568 , #1585 , #1602 , #1607 )
  • Ajouter un logo. (#1609 )
• Modifications
  • Supprimer la fonctionnalité obsolète de redémarrage en ligne (-R, aussi appelée prise de contrôle), ainsi que les commandes d’administration SHOW FDS et SUSPEND qui n’existaient que pour la prendre en charge. Utilisez à la place les redémarrages progressifs avec so_reuseport . (#1581 )
  • Augmenter la longueur maximale des mots de passe à 65535 octets, pour correspondre à libpq. (#1310 , #1520 )
  • Traiter un nom d’utilisateur NULL renvoyé par auth_query de la même manière qu’une absence de lignes renvoyées, au lieu de le traiter comme une erreur. (#1569 )
  • Accepter SET extra_float_digits sur la base de données d’administration, que les pilotes JDBC PostgreSQL récents envoient lors de la configuration de la connexion. (#1550 )
  • Permettre à mkauth.py d’écrire sur stdout en passant - comme fichier de sortie. (#1514 )
  • Ne plus consigner d’erreurs bruyantes en cas d’EOF inattendu de la part des clients lorsque PgBouncer est compilé avec OpenSSL 3. (#1507 )
  • Inclure l’erreur système sous-jacente dans les messages d’erreur TLS lorsque PgBouncer est compilé avec OpenSSL 3. (#1492 )
  • Exiger un compilateur C11. (#1417 )
  • Consigner la limite ayant provoqué l’éviction d’une connexion serveur. La raison de déconnexion est désormais evicted for max_db_connections, evicted for pool_size ou evicted for max_user_connections au lieu du simple evicted. (#1597 )
• Correctifs
  • Corriger l’épuisement du pool causé par des messages COPY tardifs en mode pooling de transactions. Cela fait également fonctionner COPY en dehors d’une transaction explicite en mode pooling de transactions. (#1471 )
  • Corriger les échecs d’authentification LDAP avec des DN longs en augmentant la longueur maximale des URL LDAP. (#1497 )
  • Corriger l’altération des identifiants en cache d’un utilisateur forcé par le pass-through SCRAM, qui entraînait l’échec des connexions au serveur, le serveur réel rejetant la preuve SCRAM. (#1612 )
  • Corriger l’échec du pass-through SCRAM avec des secrets SCRAM stockés après une reconnexion au serveur, avec l’erreur « password is SCRAM secret but client authentication did not provide SCRAM keys ». (#1504 , bogue introduit dans la version 1.25.1)
  • Corriger un plantage par use-after-free lorsqu’un client de réplication se déconnecte pendant que sa connexion serveur est encore en cours d’établissement. (#1577 )
  • Corriger l’éviction des connexions serveur inactives pour les clients de réplication lorsque le pool est plein. Auparavant, un seul client de réplication pouvait évincer tous les serveurs inactifs du pool au lieu d’un seul, et aucune éviction n’avait lieu du tout lorsque le pool contenait plus de serveurs que pool_size à cause du pool de réserve ou des requêtes d’annulation. (#1597 )
  • Corriger les connexions TLS bloquées lorsqu’un paquet chevauche la limite du tampon de paquets, par exemple un SET application_name avec une valeur longue. (#1531 )
  • Corriger l’envoi dans le mauvais ordre des réponses aux requêtes préparées lorsqu’un lot mélange des messages Parse et Close sans Sync entre eux. (#1555 )
  • Corriger le comportement incorrect, lorsque les paramètres listés dans track_extra_parameters ne sont pas rapportés par le serveur et qu’un client les définit dans son paquet de démarrage. (#1576 )
  • Corriger les échecs de connexion lorsque le serveur répartit ses paquets de connexion sur plusieurs paquets TCP, par exemple lorsqu’un autre proxy se trouve entre PgBouncer et PostgreSQL. (#1446 )
  • Corriger la fermeture de connexions par query_timeout lorsqu’aucune requête n’était en cours. (#1395 )
  • Corriger l’envoi d’un message NegotiateProtocolVersion en double lorsqu’aucun serveur n’était disponible immédiatement. (#1460 )
  • Corriger l’affichage d’une valeur dans la colonne pool_size de SHOW USERS pour les utilisateurs qui n’en ont pas de configurée. (#1489 )
  • Corriger le message d’erreur de la commande d’administration ENABLE. (#1308 )
  • Corriger la compilation avec les futures versions d’OpenSSL qui rendent struct asn1_string_st opaque. (#1440 )
  • Empêcher le compilateur d’optimiser l’effacement des données cryptographiques sensibles de la pile. (#1508 )
  • Corriger l’édition de liens de pgbevent.dll avec clang sous Windows. (#1571 )
  • Corriger les chemins des fichiers de premier niveau dans l’archive tar de publication, qui étaient stockés sous la forme pgbouncer-X.Y.Z/./configure au lieu de pgbouncer-X.Y.Z/configure. (#1549 )
  • Corriger une fuite mémoire lors de la lecture de track_extra_parameters depuis la configuration. (#1510 )
  • Corriger une fuite mémoire pour chaque paquet de démarrage contenant un paramètre d’extension de protocole (préfixe _pq_.), qui pouvait être déclenchée par des clients non authentifiés. (#1540 )

PgBouncer 1.25.x

2026-05-08 - PgBouncer 1.25.2 - « Une touche humaine et un nouveau rebondissement dans une course au titre pleine d’incertitudes »

• Sécurité

  • Correctif CVE-2026-6664 : Un 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 possible référence à un pointeur nul 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 requiert elle-même une autorisation, pouvaient exécuter cette commande. Elle ne devrait être autorisée que 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 - « La version avec la prise en charge de 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 directes 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 toute erreur survenue lors du rechargement. (#1231 )
  • Activer l’accès au socket UNIX de PgBouncer pendant l’arrêt pour les connexions administratives. Cela permet à l’opérateur de déterminer plus facilement 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 VALID UNTIL 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 annulant l’ajout de l’authentification pam dans le fichier HBA. (#1291 ) (bug introduit dans la version 1.24.0)
  • Corrige le bogue lors de la décrémentation du compteur de connexions utilisateur. Ce correctif était inclus dans l’étiquette 1.24.0 sur GitHub, mais l’archive tar de la version ne le contenait pas. (#1238 ) (bogue 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 mainteneurs de paquets Debian. (#1266 , #1250 )

• Documentation

  • Mettre à jour l’exemple d’auth_query 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 le fait de ne pas répartir la charge entre les 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 recycler les connexions lors d’un RELOAD si la configuration TLS est inchangée. Auparavant, si vous aviez des connexions TLS, elles étaient toutes recyclé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 un 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 rupture de compatibilité mineure. 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 la version minimale requise 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 - « C’est 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 à l’archive tar 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 DEALLOCATE normal reste 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 - « La version 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 le peering 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 in function client_proto(): bad client state: 6/7 » (#928 ) (bug introduit dans la version 1.18.0)
  • Correction d’un plantage avec le message d’erreur : « FATAL in function server_proto(): server in bad state: 11 » (#927 ) (bug introduit dans la version 1.18.0)
  • Réduction du niveau de journalisation pour l’envoi des 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 - « Insérer un nom amusant 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 - « Printemps ensoleillé »

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

• Correctifs
  • Correctif : FATAL in function disconnect_client(): bad client state: 0 (#846 ) (bug introduit dans la version 1.18.0)
  • Correctif : FATAL in function server_proto(): server in bad state: 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 - « À l’ancienne, fait 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 le transfert 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 vrai mystère »

• 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/SERVERS/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 d’hôtes 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 (“no such database”) 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’était pas suffisante pour des mots de passe assez longs.
  • 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 en sorte que PgBouncer, lorsqu’il agit 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 - « Un jaguar repoussé »

• 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: query end, but query_start == 0 » ont été corrigés. 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 reserve_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 « unclean server » a été clarifié. Il indique désormais « client disconnect while server was not ready » ou « client disconnect before everything was sent to the server ». 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. Certains clients étaient sinon confus. (#564 )
  • Correction des avertissements du compilateur avec GCC 11. (#623 )

PgBouncer 1.15.x

2020-11-19 - PgBouncer 1.15.0 - « J’ai encore une valise à 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 consigner 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 confus et fragile, 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 magie retrouvée »

• 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 de socket par 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 de socket SO_REUSEPORT. 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 au 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 - « L’instinct de la grandeur »

• 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 du 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 provoquait soit un plantage, soit des valeurs aberrantes 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 « bad packet header ».
• 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 « unexpected response from login query » 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 - « Survivre au chaos »

• 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 l’archive tar de distribution. Son absence empêchait totalement la compilation de l’archive tar 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, sinon gare à vous »

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 valident 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 cela devrait être sans risque, car depuis la version v1.2 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 d’ê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 - « Le public du studio approuve »

• 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.

    Il est défini dans la version 1.6.x, mais sera désactivé dans la version 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 : les versions de c-ares <= 1.10 comportent un bogue qui casse la prise en charge des CNAME lorsqu’IPv6 a été activé. (Corrigé en amont.) En contournement, c-ares <= 1.10 est utilisé en IPv4 uniquement. PgBouncer n’abandonnera donc les autres backends que lorsque c-ares >1.10 (toujours non publié) sera disponible depuis un certain temps…

  • 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 de données automatiques (autodbs)
  • 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 « bad packet » lors de la connexion lorsque l’en-tête est retardé. (Michał Trojnara, Marko Kreen)
  • Correction des erreurs détectées par Coverity. (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 - « Faire le mort pour gagner »

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

2012-11-28 - PgBouncer 1.5.4 - « Aucune fuite, apprentissage de la propreté 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 - « Grille-pain quantique »

• Correction critique

  • Les noms de base de données trop longs peuvent entraîner un plantage, ce qui est 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, rendant ainsi possible un arrêt à distance.

    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 de réessayer en cas d’EINTR provenant de close().

2012-01-05 - PgBouncer 1.5 - « Renvoi de 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 des noms d’hôtes 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 nouveau backend UDNS.
  • 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 Rembiałkowski)
  • 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 de frappe préventive »

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

• Correctifs de portabilité
  • Passer les CFLAGS à l’éditeur de liens. 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 le sigval de compatibilité du sigevent de compatibilité
  • <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 - « Tout n’était que mise en scène »

• Fonctionnalités

  • Prise en charge de l’écoute/connecter sur les adresses IPv6. (Hannu Krosing)
  • Adresses d’écoute multiples dans ’listen_addr’. Pour chacune, getaddrinfo() est appelé, et des noms peuvent donc é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.

    Les OS notablement concernés : RHEL/CentOS 5.x (glibc 2.5), Ubuntu 8.04 (glibc 2.7). Également Debian/lenny (glibc 2.7), dont le getaddrinfo_a() ne plante pas, mais nous n’avons pas de méthode fiable pour le détecter.

    Veuillez utiliser libevent 2.x sur de tels OS : le getaddrinfo_a() de repli n’est pas destiné aux systèmes de production. Lisez aussi la nouvelle section « DNS lookup support » du README pour voir comment le backend DNS est choisi.

    (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.

    Signalé par : 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 - « Code sanglant »

• 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.)

    Par défaut, il utilise getaddrinfo_a() (glibc) comme backend ; s’il n’existe pas, getaddrinfo_a() est alors émulé via getaddrinfo() bloquant (!).

    Lorsque l’argument –enable-evdns est passé à configure, le module evdns de libevent est utilisé comme backend. Il n’est pas utilisé par défaut, car libevent 1.3/1.4 contient une implémentation boguée. Seul evdns dans libevent 2.0 semble correct.

  • 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

  • Utiliser la bibliothèque libusual pour les fonctions utilitaires de bas niveau.
  • Supprimer la limite de longueur fixe des paramètres du serveur.

PgBouncer 1.3.x

2010-09-09 - PgBouncer 1.3.4 - « Le bouncer a toujours raison »

• 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 relance de l’échec rapide. L’ancienne était gênante dans le cas de bases de données ou d’utilisateurs définitivement cassés, car elle tentait de réessayer même lorsqu’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 - « Balle boomerang »

• 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.

    Ce correctif, combiné au précédent, évite des blocages inutiles lorsqu’une base de données est tombée.

  • 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.

  • Changer le message de journal pour query_timeout en « query timeout ».

2009-07-06 - PgBouncer 1.3.1 - « Conforme désormais aux exigences de surveillance de la 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 de la 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)

    Il est désormais possible de définir une base de données nommée « * ». Si elle est définie, sa chaîne de connexion sera utilisée pour toutes les bases de données non définies. Utile surtout pour les environnements de test / développement.

  • Prise en charge Windows (Hiroshi Saito)

    PgBouncer fonctionne désormais sous Windows 2000+. L’utilisation en ligne de commande reste identique, excepté qu’il ne peut pas s’exécuter en démon ni effectuer de redémarrage en ligne. Pour l’exécuter en tant que service, définissez le paramètre service_name dans la configuration. Ensuite :

    > pgbouncer.exe config.ini -regservice
    > net start SERVICE_NAME
    

    Pour arrêter et désinscrire le service :

    > net stop SERVICE_NAME
    > pgbouncer.exe config.ini -unregservice
    

    Pour utiliser le journal d’événements Windows, la DLL d’événements doit d’abord être enregistrée :

    > regsvr32 pgbevent.dll
    

    Ensuite, vous pouvez définir “syslog = 1” dans la configuration.

• 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.

    Dans certaines situations — par exemple serveur SMP, Postgres local et réseau rapide — pgbouncer peut exécuter la boucle recv()->send() de nombreuses fois sans se bloquer d’un côté ou de l’autre. Mais cela signifie que les autres connexions restent bloquées pendant longtemps. Pour rendre le traitement plus équitable, le nombre d’exécutions de recv()->send() sur une socket est limité. Si le compteur atteint la limite, le traitement passe simplement aux autres sockets. Le traitement de cette socket reprendra à la boucle d’événements suivante.

    Merci à Alexander Schöcke pour le signalement et les tests.

  • 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.

  • Ajouter des millisecondes aux horodatages de journalisation.

  • Remplacer l’ancienne implémentation MD5 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éder simplement au nettoyage. Auparavant, PgBouncer tentait de le réessayer si l’échec était dû à ENOMEM. Mais cela a provoqué des journaux inondés de répétitions infinies, si bien que libevent ne semble pas l’apprécier.

    La raison pour laquelle event_del() signale un échec la première fois reste un mystère.

  • –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 - « Octets 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 (Jørgen 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+ needed ».
  • Détecte les fichiers PID obsolètes et les supprime.

Merci à Devrim GÜNDÜZ et à Bjoern Metzdorf pour leurs rapports de problèmes et leurs tests.

2008-08-06 - PgBouncer 1.2.2 - « Sac à vomi inclus »

• Correctifs
  • Supprimer ‘drop_on_error’, c’é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 - « Étanche »

• 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
  • 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 et 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 le JDBC trop zélé, qui veut définir de manière inconditionnelle « 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 de fichiers (FD) 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 - supprimer les connexions bloquées et les connexions trop longues à s’établir. Cela apporte 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.

  • Falsifier certains paramètres dans les commandes SHOW/SET de la console pour se rapprocher davantage de Postgres. C’était nécessaire pour permettre à psycopg de se connecter à la console. (client_encoding/default_transaction_isolation/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 rend également raisonnable l’utilisation d’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 Mæhre)

PgBouncer 1.1.x

2007-12-10 - PgBouncer 1.1.2 - « Le marteau »

• 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 - « Abeille danseuse de breakdance »

• Correctifs
  • Le cache des paramètres serveur pouvait rester non initialisé, ce qui entraînait un SET inutile de ceux-ci. 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 - « Boîte à outils au chapeau fou »

• Fonctionnalités

  • Suivre 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 inactive ne la supprime plus.

  • L’annulation avec ^C depuis psql fonctionne pour SUSPEND / PAUSE.

  • Afficher les limites de descripteurs de fichiers (FD) 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 à longue durée de vie. 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 - « Avec des vitamines de A à Z »

• Correctifs
  • L’envoi de plusieurs paquets d’erreur ou de notification, avec un blocage de send() entre deux paquets, déclenchait une assertion. Le problème est corrigé en supprimant entièrement la logique de vidage. Comme PgBouncer ne met pas activement les données en tampon, cette logique n’est pas nécessaire. Il s’agissait d’un vestige de l’époque où la mise en tampon était déléguée 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 - « Dose quotidienne »

• 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 - « Assez pour aujourd’hui »

• 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 - « Le dernier “dernier bogue” »

• 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 - « Fork intrépide »

• 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.
  • Variable de configuration : client_login_timeout pour tuer les connexions mortes en phase de connexion qui pourraient bloquer SUSPEND et donc le redémarrage en ligne.

2007-03-28 - PgBouncer 1.0.2 - « Cuillère supersonique »

• 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

  • L’utilisation mixte de temps mis en cache et non mis en cache, ainsi que le typedef usec_t non signé, créaient des erreurs query_timeout 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 - « BMW tunée »

• Première version publique.

7 - Communauté

Tutoriels

• Comment configurer PgBouncer pour Postgres Plus Standard Server

  Bonne vue d’ensemble des concepts de PgBouncer.

• Quel est l’intérêt du bouncing ?

  Explique les différences entre les modes de pooling.

Assistance

• Page du projet sur GitHub

• Suivi des problèmes sur GitHub

• Section PgBouncer sur Stack Overflow

• Salon de discussion sur Gitter

• Discussions de la communauté sur GitHub

8 - Questions fréquemment posées

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 répartir la charge des requêtes entre plusieurs serveurs ?

PgBouncer prend en charge une liste d’hôtes séparés par des virgules dans une chaîne de connexion de base de données. Avec load_balance_hosts=round-robin , les nouvelles connexions serveur effectuent une rotation dans cette liste. Par exemple :

[databases]
app = host=pg1,pg2 port=5432 dbname=app load_balance_hosts=round-robin

Vous pouvez également recourir à des outils externes :

1. Round-robin DNS. Utilisez plusieurs adresses IP derrière un même nom DNS. PgBouncer ne résout pas le DNS à chaque fois qu’une nouvelle connexion est lancée. À la place, 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 backend DNS doit prendre en charge le protocole EDNS0. Voir Prise en charge des recherches DNS pour plus de détails.

2. Utilisez un répartiteur de charge de connexions TCP. LVS ou HAProxy semblent être de bons choix. 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’une répartition de charge est nécessaire.

Comment effectuer un basculement

Avec une liste d’hôtes séparés par des virgules et load_balance_hosts=disable , PgBouncer continue d’utiliser le même hôte jusqu’à ce qu’une tentative de connexion échoue, puis essaie l’hôte suivant. Cela n’effectue pas de détection de rôle primaire/réplique. Pour un basculement qui suit les évolutions de la topologie de la base de données, utilisez des outils externes :

1. 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.

2. É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.

3. 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 anciennes requêtes préparées. Cela peut être obtenu avec server_reset_query = DISCARD ALL; ou, au minimum, avec 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 pooling de transactions et s’assurer qu’elles sont préparées à la volée sur la connexion serveur liée. Pour activer cette fonctionnalité, max_prepared_statements doit être défini à une valeur non nulle (200 par défaut). 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 couper les connexions ?

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

Comment savoir quel client se trouve sur quelle connexion serveur ?

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

1. Utilisez ptr et link pour mapper la connexion client locale à la connexion serveur.

2. Utilisez addr et port de la connexion client pour identifier la connexion TCP depuis le client.

3. 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 à la fois sur le serveur web et sur le serveur de base de données. Un aspect négatif de cette approche est que chaque saut PgBouncer ajoute une petite quantité de 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 le basculement de vos applications en cas de défaillance d’un serveur web ou d’un serveur de base de données.