**log_connections** : Le paramètre `log_connections` a profondément changé en version 18. Il traçait tout ce qui concernait les connexions : la réception d'une demande de connexion, l'authentification et l'autorisation. Il est maintenant possible de sélectionner les étapes à tracer : `receipt` pour la réception, `authentication` pour l'authentification, `authorization` pour l'autorisation. Il est possible d'en spécifier plusieurs en les séparant d'une virgule, par exemple : ``` log_connections = 'receipt,authorization' ``` La granularité de cette configuration est donc plus importante et permet d'éviter des traces inutiles, même si, à l'heure actuelle, il est préconisé de les tracer toutes. Une nouvelle information est traçable : la durée des étapes d'une connexion. Cela se fait avec l'option `setup_durations` et permet d'obtenir ce type de trace : ``` LOG: connection ready: setup total=3.541 ms, fork=0.917 ms, authentication=0.576 ms ``` Dans cet exemple, la demande de connexion a duré au total 3,541 ms, sur lequel la création du processus a pris 0,917 ms et l'authentification 0,576 ms. Ces informations sont intéressantes pour prendre en compte la durée de l'authentification, notamment si vous utilisez un serveur d'authentification externe (LDAP ou Active Directory par exemple). Elles sont aussi intéressantes pour savoir si le système d'exploitation fonctionne rapidement (quand la partie `fork` est rapide). L'option `all` contient évidemment toutes les traces déjà citées (voir exemple plus bas). Les valeurs `on` et `off` sont conservées pour la compatibilité. `on` équivaut à `receipt`, `authentication`, `authorization` (donc sans `setup_durations`) pour le même comportement qu'en PostgreSQL 17. Une liste vide ou la valeur `off` désactive toute trace de connexion. **`log_line_prefix` et `%L`** : Enfin, le paramètre `log_line_prefix` dispose d'un nouveau caractère joker, `%L`, qui permet de tracer l'adresse IP **du serveur** par lequel le client s'est connecté. En effet, une instance peut répondre sur plusieurs IP différentes. Les connexions via un socket Unix affichent `[local]`. Les _background workers_ affichent `[none]`. Il est à noter que ce champ n'a pas été ajouté aux sorties `csvlog` et `jsonlog`. **Exemple** : Exemple de résultat pour une connexion avec `psql -h 127.0.0.1` (et non `localhost`, équivalent généralement à `::1`) avec `log_connections` à `all`, et `log_line_prefix` à `%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h,via %L `. ```text 2026-03-09 16:37:57 CET [597443]: [1-1] user=[unknown],db=[unknown],app=[unknown],client=127.0.0.1,via 127.0.0.1 LOG: connection received: host=127.0.0.1 port=37454 2026-03-09 16:37:57 CET [597443]: [2-1] user=postgres,db=postgres,app=[unknown],client=127.0.0.1,via 127.0.0.1 LOG: connection authenticated: identity="postgres" method=scram-sha-256 (/etc/postgresql/18/defo/pg_hba.conf:106) 2026-03-09 16:37:57 CET [597443]: [3-1] user=postgres,db=postgres,app=[unknown],client=127.0.0.1,via 127.0.0.1 LOG: connection authorized: user=postgres database=postgres application_name=psql SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256) 2026-03-09 16:37:57 CET [597443]: [4-1] user=postgres,db=postgres,app=psql,client=127.0.0.1,via 127.0.0.1 LOG: connection ready: setup total=8.861 ms, fork=0.510 ms, authentication=2.210 ms ``` On voit tout de suite la différence de durée avec une connexion _peer_ (par la _socket_ Unix) qui n'a besoin ni du SSL ni de l'authentification SCRAM, tous deux assez chronophages : ```text 2026-03-09 16:48:07 CET [600591]: [2-1] user=postgres,db=postgres,app=[unknown],client=[local],via [local] LOG: connection authenticated: identity="christ" method=peer (/etc/postgresql/18/defo/pg_hba.conf:87) 2026-03-09 16:48:07 CET [600591]: [3-1] user=postgres,db=postgres,app=[unknown],client=[local],via [local] LOG: connection authorized: user=postgres database=postgres application_name=psql 2026-03-09 16:48:07 CET [600591]: [4-1] user=postgres,db=postgres,app=psql,client=[local],via [local] LOG: connection ready: setup total=1.860 ms, fork=0.451 ms, authentication=0.177 ms ``` **log_lock_failures** : Un nouveau paramètre apparaît pour les traces : `log_lock_failures`. Il permet de tracer uniquement les demandes de verrou non satisfaites via un `SELECT … FOR UPDATE NOWAIT`. [Il y aura peut-être d'autres verrous dans le futur](https://www.postgresql.org/message-id/ecd83f43-ed95-4ccf-8503-457b2423c3e4%40oss.nttdata.com). Voici un exemple de la trace obtenue : ``` LOG: process 56906 could not obtain ShareLock on transaction 53579 DETAIL: Process holding the lock: 56228, Wait queue: . STATEMENT: SELECT * FROM t1 WHERE c1=1 FOR UPDATE NOWAIT; ``` `log_lock_failures` ne permet pas de tracer les verrous provoquant un dépassement de `lock_timeout` (1 s par défaut), si ce paramètre a été activé, Rappelons que les verrous en attente depuis plus d'une seconde (par défaut) sont déjà tracés avec `log_lock_waits` à `on`.