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-14 21:39:32
Message-ID: 01a4a798-b724-4ef3-8a44-379c430758b8@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
EDB https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2022-07-14 21:41:51 Re: doc: Clarify Routines and Extension Membership
Previous Message Tom Lane 2022-07-14 21:34:42 Re: EINTR in ftruncate()