Re: Log connection establishment timings - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Log connection establishment timings
Date
Msg-id e1586594-3b69-4aea-87ce-73a7488cdc97@eisentraut.org
Whole thread Raw
In response to Re: Log connection establishment timings  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Log connection establishment timings
List pgsql-hackers
On 12.03.25 16:43, Melanie Plageman wrote:
> On Tue, Mar 11, 2025 at 6:27 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
>>
>> I did more manual testing of my patches, and I think they are mostly
>> ready for commit except for the IsConnectionBackend() macro (if we
>> have something to change it to).
> 
> I've committed this and marked it as such in the CF app.
> Thanks to everyone for the review.

log_connections has been changed from a Boolean parameter to a string 
one, but a number of places in the documentation and in various pieces 
of test code still use the old values.  I think it would be better if 
they were adjusted to the new style.

There are two places in doc/src/sgml/config.sgml where 
log_connections=yes is used as an example.  This is a relatively 
prominent place, so it should not use deprecated values.

In src/backend/tcop/postgres.c, there is a call

         SetConfigOption("log_connections", "true", context, source);

that could be adjusted.

Various uses in test code:

src/interfaces/libpq/t/005_negotiate_encryption.pl
src/test/authentication/t/001_password.pl
src/test/authentication/t/003_peer.pl
src/test/authentication/t/005_sspi.pl
src/test/authentication/t/007_pre_auth.pl
src/test/kerberos/t/001_auth.pl
src/test/ldap/t/001_auth.pl
src/test/ldap/t/002_bindpasswd.pl
src/test/modules/ldap_password_func/t/001_mutated_bindpasswd.pl
src/test/modules/oauth_validator/t/001_server.pl
src/test/modules/oauth_validator/t/002_client.pl
src/test/postmaster/t/002_connection_limits.pl
src/test/postmaster/t/003_start_stop.pl
src/test/recovery/t/013_crash_restart.pl
src/test/recovery/t/022_crash_temp_files.pl
src/test/recovery/t/032_relfilenode_reuse.pl
src/test/recovery/t/037_invalid_database.pl
src/test/ssl/t/SSL/Server.pm
src/tools/ci/pg_ci_base.conf

I suspect in some of these cases using one of the new more granular 
values would be appropriate?  This could also serve as examples and 
testing of the parameter itself.




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Regression in statement locations
Next
From: Dmitry Dolgov
Date:
Subject: Re: queryId constant squashing does not support prepared statements