Re: Introduce "log_connection_stages" setting.

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Sergey Dudoladov" <sergey(dot)dudoladov(at)gmail(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Introduce "log_connection_stages" setting.
Date: 2022-07-12 15:22:47
Message-ID: 8cf66a46-ae53-40bd-a590-0a5adc8f7ee0@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 stages reported when
log_connections = on. It seems useful if you're only interested in (a)
malicious access or (b) authorized access (for audit purposes).

> I would like to get feedback on the following idea:
>
> Add the `log_connection_stages` setting of type “string” with possible
> values "received", "authorized", "authenticated", "disconnected", and
> "all", with "all" being the default.
> The setting would have effect only when `log_connections` is on.
> Example: log_connection_stages=’authorized,disconnected’.
> That also implies there would be no need for a separate
> "log_disconnection" setting.
Your proposal will add more confusion to the already-confused logging-related
GUCs. If you are proposing to introduce a fine-grained control, the first step
should be merge log_connections and log_disconnections into a new GUC (?) and
deprecate them. (I wouldn't introduce a new GUC that depends on the stage of
other GUC as you proposed.) There are 3 stages: connect (received), authorized
(authenticated), disconnect. You can also add 'all' that mimics log_connections
/ log_disconnections enabled. Another question is if we can reuse
log_connections for this improvement instead of a new GUC. In this case, you
would turn the boolean value into an enum value. Will it cause trouble while
upgrading to this new version? It is one of the reasons to create a new GUC. I
would suggest log_connection_messages or log_connection (with the 's' in the
end -- since it is too similar to the current GUC name, I'm afraid it is not a
good name for it).

--
Euler Taveira
EDB https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2022-07-12 15:26:08 Re: making relfilenodes 56 bits
Previous Message Alvaro Herrera 2022-07-12 15:20:59 test_oat_hooks bug (was: Re: pgsql: Add copy/equal support for XID lists)