> On 3 Jul 2023, at 15:57, Daniel Gustafsson wrote:
>
>> On 16 May 2023, at 20:51, Sergey Dudoladov
>> wrote:
>
>> I have attached the fourth version of the patch.
>
> This version fails the ldap_password test on all platforms on pg_ctl failing
> to start:
>
> [14:48:10.544] --- stdout ---
> On 16 May 2023, at 20:51, Sergey Dudoladov wrote:
> I have attached the fourth version of the patch.
This version fails the ldap_password test on all platforms on pg_ctl failing to
start:
[14:48:10.544] --- stdout ---
[14:48:10.544] # executing test in
Hello,
I have attached the fourth version of the patch.
Regards,
Sergey.
From 0303df03496ec9aafd6e69fa798177ad06a85bee Mon Sep 17 00:00:00 2001
From: Sergey Dudoladov
Date: Tue, 8 Nov 2022 18:56:26 +0100
Subject: [PATCH] Introduce 'log_connection_messages'
This patch removes 'log_connections'
On 3/2/23 14:56, Tom Lane wrote:
> Jacob Champion writes:
>> If I've understood Tom correctly in [1], both of these guc_mallocs
>> should be using a loglevel less than ERROR, to avoid forcing a
>> postmaster exit when out of memory. (I used WARNING in that thread
>> instead, which seemed to be
Jacob Champion writes:
> This is looking very good. One bigger comment:
>> +myextra = (int *) guc_malloc(ERROR, sizeof(int));
>> +*myextra = newlogconnect;
> If I've understood Tom correctly in [1], both of these guc_mallocs
> should be using a loglevel less than ERROR, to avoid forcing
On 2/1/23 11:59, Sergey Dudoladov wrote:
> Justin, thank you for the fast review. The new version is attached.
This is looking very good. One bigger comment:
> + myextra = (int *) guc_malloc(ERROR, sizeof(int));
> + *myextra = newlogconnect;
If I've understood Tom correctly in [1], both
Hi again,
Justin, thank you for the fast review. The new version is attached.
Regards,
Sergey Dudoladov
From 994a86e6ac3abb647d93bdaf0f42be76f42b83a8 Mon Sep 17 00:00:00 2001
From: Sergey Dudoladov
Date: Tue, 8 Nov 2022 18:56:26 +0100
Subject: [PATCH] Introduce 'log_connection_messages'
This
Thanks for updating the patch. It's currently failing check-world, due
to a test that was added on January 23 (a9dc7f941):
http://cfbot.cputube.org/sergey-dudoladov.html
[19:15:57.101] Summary of Failures:
[19:15:57.101] [19:15:57.101] 250/251 postgresql:ldap / ldap/002_bindpasswd
ERROR
Hello, hackers
Thank you for the reviews. I've modified the patch to incorporate your
suggestions:
+ flag bits are now used to encode different connection stages
+ failing tests are now fixed. It was not a keyword issue but rather
"check_log_connection_messages" not allocating memory properly
Hi,
+1 for the idea!
> +authenticated
> +Logs the original identity that an authentication method
> employs to identify a user. In most cases, the identity string equals the
> PostgreSQL username,
> +but some third-party authentication methods may alter the original
>
On Thu, Nov 17, 2022 at 09:36:29AM -0600, Justin Pryzby wrote:
> On Tue, Nov 08, 2022 at 07:30:38PM +0100, Sergey Dudoladov wrote:
...
Also (I didn't realize there was a CF entry), this is failing tests.
http://cfbot.cputube.org/sergey-dudoladov.html
--
Justin
On Tue, Nov 08, 2022 at 07:30:38PM +0100, Sergey Dudoladov wrote:
> +Logs reception of a connection. At this point a connection
> has been received, but no further work has been done:
receipt
> +Logs the original identity that an authentication method
> employs to identify a
Hi hackers,
I've sketched an initial patch version; feedback is welcome.
Regards,
Sergey Dudoladov
From be2e6b5c2d6fff1021f52f150b4d849dfbd26ec7 Mon Sep 17 00:00:00 2001
From: Sergey Dudoladov
Date: Tue, 8 Nov 2022 18:56:26 +0100
Subject: [PATCH] Introduce 'log_connection_messages'
This patch
On Thu, Jul 14, 2022, at 8:20 AM, Sergey Dudoladov wrote:
> I've taken connection stages and terminology from the existing log messages.
> The reason I have separated "authorized" and "authenticated" are [1]
> and [2] usages of "log_connections";
> "received" is mentioned at [3].
After checking
Hello,
Thank you for the constructive feedback.
> Your proposal will add more confusion to the already-confused logging-related
> GUCs.
> I wouldn't introduce a new GUC that depends on the stage of other GUC as you
> proposed.
Agreed, coupling a new GUC with "log_connections" is likely to
On Tue, Jul 12, 2022, at 10:52 AM, Sergey Dudoladov wrote:
> The problem we face is excessive logging of connection information
> that clutters the logs and in corner cases with many short-lived
> connections leads to disk space exhaustion.
You are proposing a fine-grained control over connection
Hello,
The problem we face is excessive logging of connection information
that clutters the logs and in corner cases with many short-lived
connections leads to disk space exhaustion.
Current connection log lines share significant parts of the
information - host, port, very close timestamps etc.
17 matches
Mail list logo
