Re: Log connection establishment timings
От | Peter Eisentraut |
---|---|
Тема | Re: Log connection establishment timings |
Дата | |
Msg-id | e1586594-3b69-4aea-87ce-73a7488cdc97@eisentraut.org обсуждение исходный текст |
Ответ на | Re: Log connection establishment timings (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Log connection establishment timings
|
Список | 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 по дате отправления: