Re: Introduce "log_connection_stages" setting.

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: Introduce "log_connection_stages" setting.
Дата
Msg-id 01a4a798-b724-4ef3-8a44-379c430758b8@www.fastmail.com
обсуждение исходный текст
Ответ на Re: Introduce "log_connection_stages" setting.  (Sergey Dudoladov <sergey.dudoladov@gmail.com>)
Ответы Re: Introduce "log_connection_stages" setting.  (Sergey Dudoladov <sergey.dudoladov@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: EINTR in ftruncate()
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: doc: Clarify Routines and Extension Membership