Re: Introduce "log_connection_stages" setting. - Mailing list pgsql-hackers

From Euler Taveira
Subject Re: Introduce "log_connection_stages" setting.
Date
Msg-id 01a4a798-b724-4ef3-8a44-379c430758b8@www.fastmail.com
Whole thread Raw
In response to Re: Introduce "log_connection_stages" setting.  (Sergey Dudoladov <sergey.dudoladov@gmail.com>)
Responses Re: Introduce "log_connection_stages" setting.
List pgsql-hackers
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 the commit 9afffcb833d, I agree that you need 4 stages:
connected, authorized, authenticated, and disconnected.

I have thought about enums too, but we need to cover arbitrary
combinations of message types, for example log only "received" and
"disconnected".
Hence the proposed type "string" with individual values within the
string really drawn from an enum.
Ooops. I said enum but I meant string list.

Are there any specific deprecation guidelines ? I have not found any
after a quick search for GUC deprecation in Google and commit history.
A deprecation scheme could look like that:
1. Mention in the docs "log_(dis)connections" are deprecated in favor
of "log_connection_stages"
2. Map "log_(dis)connections" to relevant values of
"log_connection_stages" in code if the latter is unset.
3. Complain in the logs if a conflict arises between the old params
and "log_connection_stages", with "log_connection_stages"
taking the precedence.
No. AFAICS in this case, you just remove log_connections and log_disconnections
and create the new one (see for example the commit 88e98230268 that replace
checkpoint_segments with min_wal_size and max_wal_size). We don't generally
keep ConfigureNames* entries for deprecated GUCs. Unless you are renaming a GUC
-- see map_old_guc_names; that's not the case. When we remove a GUC, we are
introducing an incompatibility so the only place it will be mentioned is the
release notes (there is a section called "Migration to Version X" that lists
all incompatibilities). From the developer's point of view, you only need to
mention in the commit message that this commit is introducing an
incompatibility. Hence, when it is time to write the release notes, the
information about the removal and the new replacement will be added.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: EINTR in ftruncate()
Next
From: Bruce Momjian
Date:
Subject: Re: doc: Clarify Routines and Extension Membership