Re: log_min_messages per backend type
On Fri, Feb 6, 2026, at 5:28 PM, surya poondla wrote:
>
> Quick clarification on how this feature interacts with existing
> per-session and per-role/database GUC settings:
> If I set log_min_messages = 'warning, backend:error' at the cluster
> level:
> 1. Can an individual session still override this with SET
> log_min_messages = DEBUG1?
> 2. Do role/database-level settings (e.g., ALTER ROLE alice SET
> log_min_messages = DEBUG1) still work as expected?
>
Yes. Yes.
> I assume both would override the cluster-level backend:error setting
> following standard GUC precedence rules, but wanted to confirm.
>
This feature doesn't change the GUC context.
postgres=# show log_min_messages;
log_min_messages
warning, backend:error
(1 row)
another terminal:
(gdb) p log_min_messages[0]@18
$16 = {19, 21, 19 }
8<-8<
postgres=# set log_min_messages to debug1;
SET
another terminal:
(gdb) p log_min_messages[0]@18
$17 = {14 }
8<-8<
postgres=# reset log_min_messages;
RESET
another terminal:
(gdb) p log_min_messages[0]@18
$18 = {19, 21, 19 }
--
Euler Taveira
EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
Hi Euler, I am still reviewing the latest patch (v11). Quick clarification on how this feature interacts with existing per-session and per-role/database GUC settings: If I set log_min_messages = 'warning, backend:error' at the cluster level: 1. Can an individual session still override this with SET log_min_messages = DEBUG1? 2. Do role/database-level settings (e.g., ALTER ROLE alice SET log_min_messages = DEBUG1) still work as expected? I assume both would override the cluster-level backend:error setting following standard GUC precedence rules, but wanted to confirm. Regards, Surya Poondla
Re: log_min_messages per backend type
On Fri, Feb 6, 2026, at 8:05 AM, Alvaro Herrera wrote:
> Here are some fixups for the main patch. I include yours so that CI
> will test this one.
>
All suggestions seem good to me.
> * I'm not fond of the term "generic", so I changed it to "default",
> which IMO makes more sense from the user point of view.
>
I'm fine with "default" instead of "generic". However, you forgot to replace
"generic" in a few places. The attached patch fixes them all.
> * There seemed to be too much guc_mallocking[*] going on; for instance for
> ptype. I simplified that by just overwriting the : to a '\0', then we
> can use the original string for pg_strcasecmp(). At the bottom of the
> loop we restore the ':', so that the code below can reuse the original
> values. This is okay because we have already mallocked a copy for
> SplitGUCList.
>
Nice trick.
> * There's no reason to add a WARNING to every process type in the
> proctypelist.h table. We can just set the values to WARNING in the
> log_min_messages initializer in guc_tables.c.
>
Ok.
> * There's no reason AFAICS to have log_min_messages_process_types in
> guc_tables.c; nobody else uses it. I made it a local array of char*
> inside the check_log_min_messages function.
>
That's true.
> * There's no need to initialize the newlevel[] array, since we're going
> to assign values to every individual element at one point or another.
> And for the assigned[] array, we don't need to set the value of each to
> 'false' in a loop; we can just initialize to '{0}' and the compiler will
> do the needful. With this we can remove the loop entirely.
>
Ok.
> * "guc_free()+list_free()+return false" the whole time in the various
> failure places across the loop was tiresome. I put them all in a single
> place and jump there with a goto.
>
I tend to avoid goto. However, in this case, it seems it improves readability.
> * in foreach() loops, tracking of a 'bool first' is unnecessary. You
> can just compare foreach_current_index() with 0.
>
Didn't know about foreach_current_index.
> * Rewrote docs and comments
>
Ok.
I attached the same patches that you shared plus the s/generic/default/ that I
said earlier for the sake of CI.
--
Euler Taveira
EDB https://www.enterprisedb.com/From 8c1fb5c97cd3fd342120f8c44d34f7bdc18e8b74 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 4 Nov 2025 17:18:20 -0300
Subject: [PATCH v11 1/3] log_min_messages per process type
Change log_min_messages from a single element to a comma-separated list
of elements. Each element is type:level. The types are archiver,
autovacuum (includes launcher and workers), backend, bgworker, bgwriter,
checkpointer, ioworker, postmaster, syslogger, slotsyncworker, startup,
walreceiver, walsender, walsummarizer and walwriter. A single log level
should be part of this list and it is applied as a final step to the
process types that were not informed.
The old syntax (a single log level) is still accepted for backward
compatibility. In this case, it means the informed log level is applied
for all process types. The default log level is the same (WARNING) for
all process types.
---
doc/src/sgml/config.sgml | 42 ++-
src/backend/commands/extension.c | 2 +-
src/backend/commands/variable.c | 256 ++
src/backend/postmaster/launch_backend.c | 2 +-
src/backend/utils/error/elog.c| 2 +-
src/backend/utils/init/miscinit.c | 2 +-
src/backend/utils/misc/guc_parameters.dat | 10 +-
src/backend/utils/misc/guc_tables.c | 21 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +
src/include/postmaster/proctypelist.h | 42 +--
src/include/utils/guc.h | 5 +-
src/include/utils/guc_hooks.h | 2 +
src/test/regress/expected/guc.out | 54
src/test/regress/sql/guc.sql | 18 ++
14 files changed, 419 insertions(+), 41 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f1af1505cf3..287816fb504 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7120,7 +7120,7 @@ local0.*/var/log/postgresql
- log_min_messages (enum)
+ log_min_messages (string)
log_min_messages configuration parameter
@@ -7129,14 +7129,38 @@ local0.*/var/log/postgresql
Controls which message
levels are written to the server log.
-Valid values are DEBUG5, DEBUG4,
-DEBUG3, DEBUG2, DEBUG1,
-INFO, NOTICE, WARNING,
-ERROR, LOG, FATAL, and
-PANIC. Each level includes all the levels that
-follow it. The later the level, the fewer messages are sent
-to the log. The default is WARNING. Note that
-LOG has a different rank here than in
+Valid values are a comma-separated list of type:level
+and a single level. The list allows it to use
+
Re: log_min_messages per backend type
Here are some fixups for the main patch. I include yours so that CI
will test this one.
* I found some errdetail messages unclear, so I reworded them.
Specifically you had
ERROR: invalid value for parameter "log_min_messages": "backend:error,
debug1, backend:warning"
DETAIL: Process type "backend" was already assigned.
which is not completely incorrect but looks weird from the user
perspective. I changed it to
DETAIL: Redundant log level specification for process type "backend".
Also,
ERROR: invalid value for parameter "log_min_messages": "debug1,
backend:error, fatal"
DETAIL: Generic log level was already assigned.
I changed to
DETAIL: Redundant specification of default log level.
and added process type in this one:
ERROR: invalid value for parameter "log_min_messages": "backend:error,
checkpointer:bar, archiver:debug1"
DETAIL: Unrecognized log level: "bar".
changed to
DETAIL: Unrecognized log level for process type "checkpointer": "bar".
(This one can show an invalid process type if the level is also bogus.
I don't think that's a terrible problem.)
* I'm not fond of the term "generic", so I changed it to "default",
which IMO makes more sense from the user point of view.
* There seemed to be too much guc_mallocking[*] going on; for instance for
ptype. I simplified that by just overwriting the : to a '\0', then we
can use the original string for pg_strcasecmp(). At the bottom of the
loop we restore the ':', so that the code below can reuse the original
values. This is okay because we have already mallocked a copy for
SplitGUCList.
* There's no reason to add a WARNING to every process type in the
proctypelist.h table. We can just set the values to WARNING in the
log_min_messages initializer in guc_tables.c.
* There's no reason AFAICS to have log_min_messages_process_types in
guc_tables.c; nobody else uses it. I made it a local array of char*
inside the check_log_min_messages function.
* There's no need to initialize the newlevel[] array, since we're going
to assign values to every individual element at one point or another.
And for the assigned[] array, we don't need to set the value of each to
'false' in a loop; we can just initialize to '{0}' and the compiler will
do the needful. With this we can remove the loop entirely.
* "guc_free()+list_free()+return false" the whole time in the various
failure places across the loop was tiresome. I put them all in a single
place and jump there with a goto.
* in foreach() loops, tracking of a 'bool first' is unnecessary. You
can just compare foreach_current_index() with 0.
* Rewrote docs and comments
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
>From a05d1e59324b7c88aeb52c009b4e03aaeafd2ffc Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 4 Nov 2025 17:18:20 -0300
Subject: [PATCH v10 1/2] log_min_messages per process type
Change log_min_messages from a single element to a comma-separated list
of elements. Each element is type:level. The types are archiver,
autovacuum (includes launcher and workers), backend, bgworker, bgwriter,
checkpointer, ioworker, postmaster, syslogger, slotsyncworker, startup,
walreceiver, walsender, walsummarizer and walwriter. A single log level
should be part of this list and it is applied as a final step to the
process types that were not informed.
The old syntax (a single log level) is still accepted for backward
compatibility. In this case, it means the informed log level is applied
for all process types. The default log level is the same (WARNING) for
all process types.
---
doc/src/sgml/config.sgml | 42 ++-
src/backend/commands/extension.c | 2 +-
src/backend/commands/variable.c | 256 ++
src/backend/postmaster/launch_backend.c | 2 +-
src/backend/utils/error/elog.c| 2 +-
src/backend/utils/init/miscinit.c | 2 +-
src/backend/utils/misc/guc_parameters.dat | 10 +-
src/backend/utils/misc/guc_tables.c | 21 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +
src/include/postmaster/proctypelist.h | 42 +--
src/include/utils/guc.h | 5 +-
src/include/utils/guc_hooks.h | 2 +
src/test/regress/expected/guc.out | 54
src/test/regress/sql/guc.sql | 18 ++
14 files changed, 419 insertions(+), 41 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 5560b95ee60..cbc748a3636 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7083,7 +7083,7 @@ local0.*/var/log/postgresql
- log_min_messages (enum)
+ log_min_messages (string)
log_min_messages configuration parameter
@@ -7092,14 +7092,38 @@ local0.*/var/log/postgresql
Controls which message
levels are written to the server log.
-Valid values are DEBUG5, DEBUG
Re: log_min_messages per backend type
Hi Euler and team, This thread is really interesting and I think the proposal clearly improves overall debuggability in Postgres. I am still catching up on the full discussion and the latest v9 patchset, but I plan to review the patches in detail and will follow-up with comments or questions, once I am done. Thanks for working on this and incorporating the feedback so far. Regards, Surya Poondla
Re: log_min_messages per backend type
On Sat, Jan 17, 2026, at 7:02 PM, Alvaro Herrera wrote: > > I'm not opposed to this idea, but I think it should be implemented not > by sorting and then moving the first element to the top of the list, but > instead by modifying the cmp function so that the desired order is > achieved directly. So the cmp() should return -1 if element a has no > colon, or 1 if element b has no colon, otherwise return per strcmp. > That way you can remove the foreach() block above, which is icky. > Good idea. The v9 contains this implementation. I also use the StringInfo as you suggested in the other email. The 0003 removed the wrong B_BACKEND assignment pointed in a previous email. This new patchset contains some changes suggested by Japin Li [1] (I didn't change the error message because it adds an extra message to translate). There was a minor issue with a null-terminated string that I fixed too. PS> I didn't change the background worker case that I mentioned in [2]. [1] https://postgr.es/m/meapr01mb3031fa1986f3fc91481e28ccb6...@meapr01mb3031.ausprd01.prod.outlook.com [2] https://postgr.es/m/[email protected] -- Euler Taveira EDB https://www.enterprisedb.com/From ea299f1a8b6a38e40826d7baf0dd7a6733197fb4 Mon Sep 17 00:00:00 2001 From: Euler Taveira Date: Tue, 4 Nov 2025 17:18:20 -0300 Subject: [PATCH v9 1/3] log_min_messages per process type Change log_min_messages from a single element to a comma-separated list of elements. Each element is type:level. The types are archiver, autovacuum (includes launcher and workers), backend, bgworker, bgwriter, checkpointer, ioworker, postmaster, syslogger, slotsyncworker, startup, walreceiver, walsender, walsummarizer and walwriter. A single log level should be part of this list and it is applied as a final step to the process types that were not informed. The old syntax (a single log level) is still accepted for backward compatibility. In this case, it means the informed log level is applied for all process types. The default log level is the same (WARNING) for all process types. --- doc/src/sgml/config.sgml | 42 +++- src/backend/commands/extension.c | 2 +- src/backend/commands/variable.c | 206 ++ src/backend/postmaster/launch_backend.c | 2 +- src/backend/utils/error/elog.c| 2 +- src/backend/utils/init/miscinit.c | 2 +- src/backend/utils/misc/guc_parameters.dat | 10 +- src/backend/utils/misc/guc_tables.c | 21 +- src/backend/utils/misc/postgresql.conf.sample | 2 + src/include/postmaster/proctypelist.h | 42 ++-- src/include/utils/guc.h | 5 +- src/include/utils/guc_hooks.h | 2 + src/test/regress/expected/guc.out | 54 + src/test/regress/sql/guc.sql | 18 ++ 14 files changed, 369 insertions(+), 41 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5560b95ee60..cbc748a3636 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -7083,7 +7083,7 @@ local0.*/var/log/postgresql - log_min_messages (enum) + log_min_messages (string) log_min_messages configuration parameter @@ -7092,14 +7092,38 @@ local0.*/var/log/postgresql Controls which message levels are written to the server log. -Valid values are DEBUG5, DEBUG4, -DEBUG3, DEBUG2, DEBUG1, -INFO, NOTICE, WARNING, -ERROR, LOG, FATAL, and -PANIC. Each level includes all the levels that -follow it. The later the level, the fewer messages are sent -to the log. The default is WARNING. Note that -LOG has a different rank here than in +Valid values are a comma-separated list of type:level +and a single level. The list allows it to use +different levels per process type. Only the single level +is mandatory (order does not matter) and it is assigned to the process +types that are not specified in the list. +Valid process types are listed in the table below, each corresponding to +either postmaster, an auxiliary process type or a backend. + + archiver + autovacuum + backend + bgworker + bgwriter + checkpointer + ioworker + postmaster + syslogger + slotsyncworker + startup + walreceiver + walsender + walsummarizer + walwriter + +Valid level values are DEBUG5, +DEBUG4, DEBUG3, DEBUG2, +DEBUG1, INFO, NOTICE, +WARNING, ERROR, LOG, +FATAL, and PANIC. Each level includes +all the levels that follow it. The later the level, the fewer messages are sent +to the log. The default is WARNING for all process types. +Note that LOG has a differen
Re: log_min_messages per backend type
On 2026-Jan-15, Euler Taveira wrote: > @@ -586,6 +588,8 @@ SubPostmasterMain(int argc, char *argv[]) > IsPostmasterEnvironment = true; > whereToSendOutput = DestNone; > > + MyBackendType = B_BACKEND; > + > /* >* Capture the end of process creation for logging. We don't include the >* time spent copying data from shared memory and setting up the > backend. BTW I think SubPostmasterMain() shouldn't do this. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Curiosity is the hope that something wondrous waits just out of sight, for we are surrounded by a garden of miracles" (Namron) (Marjorie Liu and Sana Takeda, Monstress: Inferno)
Re: log_min_messages per backend type
On 2026-Jan-15, Euler Taveira wrote:
> @@ -1275,10 +1279,16 @@ check_log_min_messages(char **newval, void **extra,
> GucSource source)
> char *rawstring;
> List *elemlist;
> ListCell *l;
> + char *result;
> + boolfirst = true;
> int newlevel[BACKEND_NUM_TYPES];
> boolassigned[BACKEND_NUM_TYPES];
> int genericlevel = -1; /* -1 means not
> assigned */
>
> + result = (char *) guc_malloc(LOG, MAX_LMM_STR_LEN);
> + if (!result)
> + return false;
...
> + foreach(l, elemlist)
> + {
> + char *tok = (char *) lfirst(l);
> +
> + if (first)
> + {
> + strncpy(result, tok, MAX_LMM_STR_LEN);
> + first = false;
> + }
> + else
> + {
> + strlcat(result, ", ", MAX_LMM_STR_LEN);
> + strlcat(result, tok, MAX_LMM_STR_LEN);
> + }
> + }
BTW I think this whole MAX_LMM_STR_LEN thing is unnecessary. It is
probably easy enough to use a StringInfo to create the value
iteratively, then once you know its final length do a guc_malloc() and
strcpy the value there.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)
Re: log_min_messages per backend type
On 2026-Jan-15, Euler Taveira wrote: > On Tue, Dec 9, 2025, at 1:30 PM, Alvaro Herrera wrote: > > BTW another thing I realized while looking this over, is that we quite > > uselessly transform the integer backend type to a string, pass it as a > > string using the --forkchild= argument to the child process, then parse > > the string back to an int to use as an array index. It would be much > > easier to just use the integer value everywhere, as the attached shows. > > > > It is a good simplification. Thanks! Pushed. > There is just one oversight. > > + child_type = (BackendType) atoi(child_kind); > + if (child_type <= B_INVALID || child_type > BACKEND_NUM_TYPES) > elog(ERROR, "unknown child kind %s", child_kind); > > It should be BACKEND_NUM_TYPES - 1. Good catch, thanks. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Digital and video cameras have this adjustment and film cameras don't for the same reason dogs and cats lick themselves: because they can." (Ken Rockwell)
Re: log_min_messages per backend type
On 2026-Jan-15, Euler Taveira wrote:
> + /*
> + * Use a stable representation of log_min_messages. The generic level is
> + * always the first element and the other elements (type:level) are
> sorted
> + * by process type.
> + */
> + list_sort(elemlist, string_cmp);
> + foreach(l, elemlist)
> + {
> + char *tok = (char *) lfirst(l);
> +
> + if (strchr(tok, ':') == NULL)
> + {
> + elemlist = list_delete(elemlist, tok);
> + elemlist = lcons(tok, elemlist);
> + break;
> + }
> + }
> +static int
> +string_cmp(const ListCell *a, const ListCell *b)
> +{
> + const char *s = lfirst(a);
> + const char *t = lfirst(b);
> +
> + return strcmp(s, t);
> +}
I'm not opposed to this idea, but I think it should be implemented not
by sorting and then moving the first element to the top of the list, but
instead by modifying the cmp function so that the desired order is
achieved directly. So the cmp() should return -1 if element a has no
colon, or 1 if element b has no colon, otherwise return per strcmp.
That way you can remove the foreach() block above, which is icky.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Computing is too important to be left to men." (Karen Spärck Jones)
Re: log_min_messages per backend type
Hi Euler,
On Thu, 15 Jan 2026 at 13:07, "Euler Taveira" wrote:
> On Tue, Dec 9, 2025, at 3:24 PM, Alvaro Herrera wrote:
>> On 2025-Dec-09, Alvaro Herrera wrote:
>>
>>> So here's your v6 again with those fixes as 0003 -- let's see what CI
>>> thinks of this. I haven't looked at your doc changes yet.
>>
>> This passed CI, so I have marked it as Ready for Committer. Further
>> comments are still welcome, of course, but if there are none, I intend
>> to get it committed in a few days.
>>
>
> I took another look after Chao Li comments [1]. I created the 0003 patch
> that does the sort as suggested. I think it is good to be consistent but
> I'm fine if we decided the additional code is not worth. The 32 in the
> MAX_LMM_STR_LEN is arbitrary but it is based on the size of the largest
> element in the list ("dead-end client backend:warning"). I didn't take
> into account the comma and space between elements but it is not
> necessary since other elements are smaller than the largest one.
> I didn't implement the 2nd suggestion.
>
> I also merged Alvaro's fix to 0002. The v8 is attached.
>
> I didn't change the commit message but if 0003 is merged into 0001 then
> it should mention that
>
> 8<8<
> The SHOW command presents well-formatted list sorted by process type and
> the generic log level is the first element list. It improves readability
> and has a clear indentation.
> 8<8<
>
> Do we really need a different backend type in this case? For background
> workers the description is "background worker". Shoundn't it use the
> same description for this edge case too?
>
> - backend_type_str = MyBgworkerEntry->bgw_type;
> + {
> + if (MyBgworkerEntry && MyBgworkerEntry->bgw_type[0] != '\0')
> + backend_type_str = MyBgworkerEntry->bgw_type;
> + else
> + backend_type_str = "early bgworker";
> + }
>
> I also noticed that commit 18d67a8d7d30 forgot to add gettext_noop to
> the get_backend_type_for_log function. It should be consistent with
> GetBackendTypeDesc() return.
>
>
> [1] https://postgr.es/m/[email protected]
>
>
Thanks for updating the patch set.
Here are some comments.
1.
We can replace foreach with foreach_ptr in both v8-0001 and v8-0003.
2.
+/* log_min_messages */
+extern PGDLLIMPORT const char *const log_min_messages_process_types[];
+
Comment looks wrong.
3.
For cases where the process type is valid but the log level is unrecognized,
I suggest improving the error message for better clarity, e.g.:
Unrecognized log level "bar" for process type "backend"
4.
The function name string_cmp feels too generic.
Could we consider a more specific name, for example list_log_min_message_cmp
or another more appropriate one?
> --
> Euler Taveira
> EDB https://www.enterprisedb.com/
>
> [2. text/x-patch; v8-0001-log_min_messages-per-process-type.patch]...
>
> [3. text/x-patch; v8-0002-Assign-backend-type-earlier.patch]...
>
> [4. text/x-patch; v8-0003-fixup-log_min_messages-per-process-type.patch]...
--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.
Re: log_min_messages per backend type
On Tue, Dec 9, 2025, at 3:24 PM, Alvaro Herrera wrote:
> On 2025-Dec-09, Alvaro Herrera wrote:
>
>> So here's your v6 again with those fixes as 0003 -- let's see what CI
>> thinks of this. I haven't looked at your doc changes yet.
>
> This passed CI, so I have marked it as Ready for Committer. Further
> comments are still welcome, of course, but if there are none, I intend
> to get it committed in a few days.
>
I took another look after Chao Li comments [1]. I created the 0003 patch
that does the sort as suggested. I think it is good to be consistent but
I'm fine if we decided the additional code is not worth. The 32 in the
MAX_LMM_STR_LEN is arbitrary but it is based on the size of the largest
element in the list ("dead-end client backend:warning"). I didn't take
into account the comma and space between elements but it is not
necessary since other elements are smaller than the largest one.
I didn't implement the 2nd suggestion.
I also merged Alvaro's fix to 0002. The v8 is attached.
I didn't change the commit message but if 0003 is merged into 0001 then
it should mention that
8<8<
The SHOW command presents well-formatted list sorted by process type and
the generic log level is the first element list. It improves readability
and has a clear indentation.
8<8<
Do we really need a different backend type in this case? For background
workers the description is "background worker". Shoundn't it use the
same description for this edge case too?
- backend_type_str = MyBgworkerEntry->bgw_type;
+ {
+ if (MyBgworkerEntry && MyBgworkerEntry->bgw_type[0] != '\0')
+ backend_type_str = MyBgworkerEntry->bgw_type;
+ else
+ backend_type_str = "early bgworker";
+ }
I also noticed that commit 18d67a8d7d30 forgot to add gettext_noop to
the get_backend_type_for_log function. It should be consistent with
GetBackendTypeDesc() return.
[1] https://postgr.es/m/[email protected]
--
Euler Taveira
EDB https://www.enterprisedb.com/From 7b327eacb382c7efe7c7fcab309bb04c0043507d Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 4 Nov 2025 17:18:20 -0300
Subject: [PATCH v8 1/3] log_min_messages per process type
Change log_min_messages from a single element to a comma-separated list
of elements. Each element is type:level. The types are archiver,
autovacuum (includes launcher and workers), backend, bgworker, bgwriter,
checkpointer, ioworker, postmaster, syslogger, slotsyncworker, startup,
walreceiver, walsender, walsummarizer and walwriter. A single log level
should be part of this list and it is applied as a final step to the
process types that were not informed.
The old syntax (a single log level) is still accepted for backward
compatibility. In this case, it means the informed log level is applied
for all process types. The default log level is the same (WARNING) for
all process types.
---
doc/src/sgml/config.sgml | 42 +++-
src/backend/commands/extension.c | 2 +-
src/backend/commands/variable.c | 208 ++
src/backend/postmaster/launch_backend.c | 2 +-
src/backend/utils/error/elog.c| 2 +-
src/backend/utils/init/miscinit.c | 2 +-
src/backend/utils/misc/guc_parameters.dat | 10 +-
src/backend/utils/misc/guc_tables.c | 21 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +
src/include/postmaster/proctypelist.h | 42 ++--
src/include/utils/guc.h | 6 +-
src/include/utils/guc_hooks.h | 2 +
src/test/regress/expected/guc.out | 54 +
src/test/regress/sql/guc.sql | 18 ++
14 files changed, 372 insertions(+), 41 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0fad34da6eb..4df87e1bc52 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7083,7 +7083,7 @@ local0.*/var/log/postgresql
- log_min_messages (enum)
+ log_min_messages (string)
log_min_messages configuration parameter
@@ -7092,14 +7092,38 @@ local0.*/var/log/postgresql
Controls which message
levels are written to the server log.
-Valid values are DEBUG5, DEBUG4,
-DEBUG3, DEBUG2, DEBUG1,
-INFO, NOTICE, WARNING,
-ERROR, LOG, FATAL, and
-PANIC. Each level includes all the levels that
-follow it. The later the level, the fewer messages are sent
-to the log. The default is WARNING. Note that
-LOG has a different rank here than in
+Valid values are a comma-separated list of type:level
+and a single level. The list allows it to use
+different levels per process type. Only the single level
+is mandatory (order does not
Re: log_min_messages per backend type
On Tue, Dec 9, 2025, at 1:30 PM, Alvaro Herrera wrote: > BTW another thing I realized while looking this over, is that we quite > uselessly transform the integer backend type to a string, pass it as a > string using the --forkchild= argument to the child process, then parse > the string back to an int to use as an array index. It would be much > easier to just use the integer value everywhere, as the attached shows. > It is a good simplification. There is just one oversight. + child_type = (BackendType) atoi(child_kind); + if (child_type <= B_INVALID || child_type > BACKEND_NUM_TYPES) elog(ERROR, "unknown child kind %s", child_kind); It should be BACKEND_NUM_TYPES - 1. -- Euler Taveira EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
> On Dec 11, 2025, at 09:57, Euler Taveira wrote: > > >> In the “if” and “else” clauses, there are duplicate code to valid log >> levels. We should refactor the code to avoid the duplication. For >> example, pull up “loglevel” to the “for” loop level, then we can valid >> it after the “if-else”. >> > > The for loop is duplicate but if you create a separate function for it but the > result is: > > src/backend/commands/variable.c | 43 > ++- > 1 file changed, 22 insertions(+), 21 deletions(-) > > I don’t think we need to add a separate function. We can use ‘if-else” to parse log level, then verify it after “if-else”. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
Re: log_min_messages per backend type
On Tue, Dec 9, 2025, at 11:00 PM, Chao Li wrote: > Now “show log_min_messages” prints the raw string the user set, in > above example, there is not a white-space between the two log levels, > and “show” result doesn’t have a white-space between the two log levels > either. IMO, “SHOW log_min_messages” should display a stable result, in > other words, say “fatal, backend:log” and “backend:log, fatal” should > show the same result as they are actually meaning the same. So, I would > suggest normalize the raw string: put the general level in the first > place and sort others by process type, then SHOW returns the normalized > string. > I thought about it but leave it alone because (a) it would increase this patch footprint and (b) the input might be different from the output. I could also be done in another patch but under reflection an unstable output can break tests or whatever uses the SHOW log_min_messages output. I thought this change would require a new show_log_min_messages to manipulate the input again but we can reassign the GUC value after sorting the existing list and creating a new string list. > In the “if” and “else” clauses, there are duplicate code to valid log > levels. We should refactor the code to avoid the duplication. For > example, pull up “loglevel” to the “for” loop level, then we can valid > it after the “if-else”. > The for loop is duplicate but if you create a separate function for it but the result is: src/backend/commands/variable.c | 43 ++- 1 file changed, 22 insertions(+), 21 deletions(-) I'll post a patch in a couple of hours after spend more time in it. -- Euler Taveira EDB https://www.enterprisedb.com/
Re?? log_min_messages per backend type
Hi,
I applied this patch, and I have a few thoughts.
=== Issue 1: Unhelpful error messages for typos ===
When users make typos in process types or log levels, the current error
messages don't provide helpful hints. For example:
```
testdb=# SET log_min_messages TO 'autovacum:debug1, warning';
ERROR: invalid value for parameter "log_min_messages":
"autovacum:debug1, warning"
DETAIL: Unrecognized process type: "autovacum".
testdb=# SET log_min_messages TO 'autovacuum:debug1, warnong';
ERROR: invalid value for parameter "log_min_messages":
"autovacuum:debug1, warnong"
DETAIL: Unrecognized log level: "warnong".
```
typed in a wrong process type or log level, I got stuck.
Where to find the right values? We can add HINT, to list all candidate values.
I have seen a similar change that lists all valid values in HINT. See [1].
=== Issue 2: Confusing error message for duplicate generic settings ===
The error message for duplicate generic log levels isn't immediately clear:
```
testdb=# SET log_min_messages TO 'debug1, backend:error, fatal';
ERROR: invalid value for parameter "log_min_messages":
"debug1, backend:error, fatal"
DETAIL: Generic log level was already assigned.
```
This DETAIL message is unclear. It leads to a misunderstanding that a previous
SET had assigned the generic log level.
I think "Only one default log level may be specified.?? would be better.
=== Issue 3: Minor optimization for ptype allocation ===
In the following code snippet:
```
+ ptype = guc_malloc(LOG, (sep - tok) + 1);
+ if (!ptype)
+ {
+ guc_free(rawstring);
+ list_free(elemlist);
+ return false;
+ }
```
"ptype" is a temp buffer to store parsed process type, I think it can be
allocated from stack. Because the valid values are not long
we could use like:
char ptype[MAXNAMELEN];
This would eliminate the need for allocation failure handling and simplify
memory management, as we wouldn't need to worry about freeing it before
every return path.
[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=99780da7209605bf9f226eac3eac30ab2bc9427c
-- --
??:
"Alvaro Herrera"
https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A. Stepanov)
Re: log_min_messages per backend type
> On Dec 10, 2025, at 02:24, Alvaro Herrera wrote:
>
> On 2025-Dec-09, Alvaro Herrera wrote:
>
>> So here's your v6 again with those fixes as 0003 -- let's see what CI
>> thinks of this. I haven't looked at your doc changes yet.
>
> This passed CI, so I have marked it as Ready for Committer. Further
> comments are still welcome, of course, but if there are none, I intend
> to get it committed in a few days.
>
>
> I'm not really happy with our usage of the translatable description
> field for things such as %b in log_line_prefix or the ps display; I
> think we should use the shorter names there instead. Otherwise, you end
> up with log lines that look something like this (visible in a server
> with %b in log_line_prefix, which the TAP tests as well as pg_regress
> have):
>
> 2025-12-08 21:38:04.304 CET autovacuum launcher[2452437] DEBUG: autovacuum
> launcher started
>
> where the bit before the PID is marked for translation. I think it
> should rather be
>
> 2025-12-08 21:38:04.304 CET autovacuum[2452437] DEBUG: autovacuum launcher
> started
>
> where that name (the same we'll use in log_min_messages) is not
> translated.
>
> However, this issue is rather independent of the patch in this thread,
> so I'm going to discuss it in another thread; the name string though is
> added by this patch.
>
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "Java is clearly an example of money oriented programming" (A. Stepanov)
Overall the patch is solid, I just have a couple of suggestions:
1 - user experience
```
evantest=# show log_min_messages;
log_min_messages
-
warning,backend:log
(1 row)
```
Now “show log_min_messages” prints the raw string the user set, in above
example, there is not a white-space between the two log levels, and “show”
result doesn’t have a white-space between the two log levels either. IMO, “SHOW
log_min_messages” should display a stable result, in other words, say “fatal,
backend:log” and “backend:log, fatal” should show the same result as they are
actually meaning the same. So, I would suggest normalize the raw string: put
the general level in the first place and sort others by process type, then SHOW
returns the normalized string.
2 - refactoring for 0001
```
+ sep = strchr(tok, ':');
+ if (sep == NULL)
+ {
+ boolfound = false;
+
+ /* Reject duplicates for generic log level. */
+ if (genericlevel != -1)
+ {
+ GUC_check_errdetail("Generic log level was
already assigned.");
+ guc_free(rawstring);
+ list_free(elemlist);
+ return false;
+ }
+
+ /* Is the log level valid? */
+ for (entry = server_message_level_options; entry &&
entry->name; entry++)
+ {
+ if (pg_strcasecmp(entry->name, tok) == 0)
+ {
+ genericlevel = entry->val;
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ {
+ GUC_check_errdetail("Unrecognized log level:
\"%s\".", tok);
+ guc_free(rawstring);
+ list_free(elemlist);
+ return false;
+ }
+ }
+ else
+ {
+ char *loglevel;
+ char *ptype;
+ boolfound = false;
+
+ ptype = guc_malloc(LOG, (sep - tok) + 1);
+ if (!ptype)
+ {
+ guc_free(rawstring);
+ list_free(elemlist);
+ return false;
+ }
+ memcpy(ptype, tok, sep - tok);
+ ptype[sep - tok] = '\0';
+ loglevel = sep + 1;
+
+ /* Is the log level valid? */
+ for (entry = server_message_level_options; entry &&
entry->name; entry++)
+ {
+ if (pg_strcasecmp(entry->name, loglevel) == 0)
+ {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ {
+ GUC_check_errdetail("Unrecognized log level:
\"%s\".", loglev
Re: log_min_messages per backend type
On 2025-Dec-09, Alvaro Herrera wrote: > So here's your v6 again with those fixes as 0003 -- let's see what CI > thinks of this. I haven't looked at your doc changes yet. This passed CI, so I have marked it as Ready for Committer. Further comments are still welcome, of course, but if there are none, I intend to get it committed in a few days. I'm not really happy with our usage of the translatable description field for things such as %b in log_line_prefix or the ps display; I think we should use the shorter names there instead. Otherwise, you end up with log lines that look something like this (visible in a server with %b in log_line_prefix, which the TAP tests as well as pg_regress have): 2025-12-08 21:38:04.304 CET autovacuum launcher[2452437] DEBUG: autovacuum launcher started where the bit before the PID is marked for translation. I think it should rather be 2025-12-08 21:38:04.304 CET autovacuum[2452437] DEBUG: autovacuum launcher started where that name (the same we'll use in log_min_messages) is not translated. However, this issue is rather independent of the patch in this thread, so I'm going to discuss it in another thread; the name string though is added by this patch. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "Java is clearly an example of money oriented programming" (A. Stepanov)
Re: log_min_messages per backend type
BTW another thing I realized while looking this over, is that we quite
uselessly transform the integer backend type to a string, pass it as a
string using the --forkchild= argument to the child process, then parse
the string back to an int to use as an array index. It would be much
easier to just use the integer value everywhere, as the attached shows.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"I love the Postgres community. It's all about doing things _properly_. :-)"
(David Garamond)
>From 4c2e63bc3c78b567e83a4d6d0df60ddeb0f51a3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C3=81lvaro=20Herrera?=
Date: Tue, 9 Dec 2025 15:29:43 +0100
Subject: [PATCH] Use integers not strings to identify backend type
---
src/backend/postmaster/launch_backend.c | 32 +
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/src/backend/postmaster/launch_backend.c
b/src/backend/postmaster/launch_backend.c
index 976638a58ac..3606a569758 100644
--- a/src/backend/postmaster/launch_backend.c
+++ b/src/backend/postmaster/launch_backend.c
@@ -162,7 +162,7 @@ static bool save_backend_variables(BackendParameters
*param, int child_slot,
#endif
const void
*startup_data, size_t startup_data_len);
-static pid_t internal_forkexec(const char *child_kind, int child_slot,
+static pid_t internal_forkexec(int child_kind, int child_slot,
const void
*startup_data, size_t startup_data_len,
ClientSocket
*client_sock);
@@ -217,7 +217,7 @@ postmaster_child_launch(BackendType child_type, int
child_slot,
((BackendStartupData *) startup_data)->fork_started =
GetCurrentTimestamp();
#ifdef EXEC_BACKEND
- pid = internal_forkexec(child_process_kinds[child_type].name,
child_slot,
+ pid = internal_forkexec(child_type, child_slot,
startup_data,
startup_data_len, client_sock);
/* the child process will arrive in SubPostmasterMain */
#else /* !EXEC_BACKEND */
@@ -282,7 +282,7 @@ postmaster_child_launch(BackendType child_type, int
child_slot,
* - fork():s, and then exec():s the child process
*/
static pid_t
-internal_forkexec(const char *child_kind, int child_slot,
+internal_forkexec(int child_kind, int child_slot,
const void *startup_data, size_t
startup_data_len, ClientSocket *client_sock)
{
static unsigned long tmpBackendFileNum = 0;
@@ -358,7 +358,7 @@ internal_forkexec(const char *child_kind, int child_slot,
/* set up argv properly */
argv[0] = "postgres";
- snprintf(forkav, MAXPGPATH, "--forkchild=%s", child_kind);
+ snprintf(forkav, MAXPGPATH, "--forkchild=%d", child_kind);
argv[1] = forkav;
/* Insert temp file name after --forkchild argument */
argv[2] = tmpfilename;
@@ -392,7 +392,7 @@ internal_forkexec(const char *child_kind, int child_slot,
* file is complete.
*/
static pid_t
-internal_forkexec(const char *child_kind, int child_slot,
+internal_forkexec(int child_kind, int child_slot,
const void *startup_data, size_t
startup_data_len, ClientSocket *client_sock)
{
int retry_count = 0;
@@ -444,7 +444,7 @@ retry:
#else
sprintf(paramHandleStr, "%lu", (DWORD) paramHandle);
#endif
- l = snprintf(cmdLine, sizeof(cmdLine) - 1, "\"%s\" --forkchild=\"%s\"
%s",
+ l = snprintf(cmdLine, sizeof(cmdLine) - 1, "\"%s\" --forkchild=%d %s",
postgres_exec_path, child_kind,
paramHandleStr);
if (l >= sizeof(cmdLine))
{
@@ -567,8 +567,8 @@ retry:
* to what it would be if we'd simply forked on Unix, and
then
* dispatch to the appropriate place.
*
- * The first two command line arguments are expected to be
"--forkchild=",
- * where indicates which postmaster child we are to become, and
+ * The first two command line arguments are expected to be
"--forkchild=",
+ * where indicates which process type we are to become, and
* the name of a variables file that we can read to load data that would
* have been inherited by fork() on Unix.
*/
@@ -579,7 +579,6 @@ SubPostmasterMain(int argc, char *argv[])
size_t startup_data_len;
char *child_kind;
BackendType child_type;
- boolfound = false;
TimestampTz fork_end;
/* In EXEC_BACKEND case we will not have inherited these settings */
@@ -599,21 +598,12 @@ SubPostmasterMain(int argc, char *argv[])
if (argc != 3)
elog(FATAL, "invalid subpostmaster invocation");
- /* Find the entry in child_process_kinds */
+ /* Parse t
Re: log_min_messages per backend type
Hello I noticed failures under Windows, and realized that the EXEC_BACKEND case was busted. That's easy to fix -- just assign MyBackendType in SubPostmasterMain() as well. With that fix I was still getting some crashes in three test modules, and after some debugging it turned out that if you have shared_preload_library with a background worker and use %b in the log_line_prefix, you get a crash trying to expand a name that hasn't been set up yet. I figured we can use a constant string in that case. Better ideas for that string welcome. So here's your v6 again with those fixes as 0003 -- let's see what CI thinks of this. I haven't looked at your doc changes yet. BTW with %b in log_line_prefix, the log file looks ... interesting. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers >From d6e56c7259088529ae7a114f57f4dc875697dd97 Mon Sep 17 00:00:00 2001 From: Euler Taveira Date: Tue, 4 Nov 2025 17:18:20 -0300 Subject: [PATCH v7 1/3] log_min_messages per process type Change log_min_messages from a single element to a comma-separated list of elements. Each element is type:level. The types are archiver, autovacuum (includes launcher and workers), backend, bgworker, bgwriter, checkpointer, ioworker, postmaster, syslogger, slotsyncworker, startup, walreceiver, walsender, walsummarizer and walwriter. A single log level should be part of this list and it is applied as a final step to the process types that were not informed. The old syntax (a single log level) is still accepted for backward compatibility. In this case, it means the informed log level is applied for all process types. The default log level is the same (WARNING) for all process types. --- doc/src/sgml/config.sgml | 42 +++- src/backend/commands/extension.c | 2 +- src/backend/commands/variable.c | 208 ++ src/backend/postmaster/launch_backend.c | 2 +- src/backend/utils/error/elog.c| 2 +- src/backend/utils/init/miscinit.c | 2 +- src/backend/utils/misc/guc_parameters.dat | 10 +- src/backend/utils/misc/guc_tables.c | 21 +- src/backend/utils/misc/postgresql.conf.sample | 2 + src/include/postmaster/proctypelist.h | 42 ++-- src/include/utils/guc.h | 6 +- src/include/utils/guc_hooks.h | 2 + src/test/regress/expected/guc.out | 54 + src/test/regress/sql/guc.sql | 18 ++ 14 files changed, 372 insertions(+), 41 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 405c9689bd0..62d6c0d36a2 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -7069,7 +7069,7 @@ local0.*/var/log/postgresql - log_min_messages (enum) + log_min_messages (string) log_min_messages configuration parameter @@ -7078,14 +7078,38 @@ local0.*/var/log/postgresql Controls which message levels are written to the server log. -Valid values are DEBUG5, DEBUG4, -DEBUG3, DEBUG2, DEBUG1, -INFO, NOTICE, WARNING, -ERROR, LOG, FATAL, and -PANIC. Each level includes all the levels that -follow it. The later the level, the fewer messages are sent -to the log. The default is WARNING. Note that -LOG has a different rank here than in +Valid values are a comma-separated list of type:level +and a single level. The list allows it to use +different levels per process type. Only the single level +is mandatory (order does not matter) and it is assigned to the process +types that are not specified in the list. +Valid process types are listed in the table below, each corresponding to +either postmaster, an auxiliary process type or a backend. + + archiver + autovacuum + backend + bgworker + bgwriter + checkpointer + ioworker + postmaster + syslogger + slotsyncworker + startup + walreceiver + walsender + walsummarizer + walwriter + +Valid level values are DEBUG5, +DEBUG4, DEBUG3, DEBUG2, +DEBUG1, INFO, NOTICE, +WARNING, ERROR, LOG, +FATAL, and PANIC. Each level includes +all the levels that follow it. The later the level, the fewer messages are sent +to the log. The default is WARNING for all process types. +Note that LOG has a different rank here than in . Only superusers and users with the appropriate SET privilege can change this setting. diff --git a/src
Re: log_min_messages per backend type
On Thu, Nov 6, 2025, at 11:53 AM, Chao Li wrote:
> I just reviewed the patch and got a few comments.
>
Thanks for your review.
> + /* Initialize the array. */
> + memset(newlevel, WARNING, BACKEND_NUM_TYPES * sizeof(int));
> ```
>
> I think this statement is wrong, because memset() writes bytes but
> integers, so this statement will set very byte to WARNING, which should
> not be the intention. You will need to use a loop to initialize every
> element of newlevel.
>
Facepalm. Good catch.
> 2 - variable.c
> ```
> + /* Parse string into list of identifiers. */
> + if (!SplitGUCList(rawstring, ',', &elemlist))
> + {
> + /* syntax error in list */
> + GUC_check_errdetail("List syntax is invalid.");
> + guc_free(rawstring);
> + list_free(elemlist);
> + return false;
> + }
> ```
>
> Every element of elemlist points to a position of rawstring, so it’s
> better to list_free(elemlist) first then guc_free(rawstring).
>
Fixed.
> 3 - launch_backend.c
> ```
> static inline bool
> should_output_to_server(int elevel)
> {
> - return is_log_level_output(elevel, log_min_messages);
> + return is_log_level_output(elevel, log_min_messages[MyBackendType]);
> }
> ```
>
> Is it possible that when this function is called, MyBackendType has not
> been initialized? To be safe, maybe we can check if MyBackendType is 0
> (B_INVALID), then use the generic log_min_message.
>
It uses the generic log level if you don't modify backend type "backend". If
you do specify "backend", that level is used instead. After Alvaro's question
in the other email, I added "postmaster" backend type and assigned it to
B_INVALID. That's exactly the log level that will be used. As I said in that
email, it is ok to consider a process whose backend type is B_INVALID as a
postmaster process.
> * “Valid values are …”, here “are” usually mean both are needed, so
> maybe change “are” to “can be”.
> * It says “the single level is mandatory”, then why there is still a
> default value?
>
It seems the current sentence that describe the comma-separated list is
ambiguous. The sentence doesn't make it clear that the list contains 2 elements
(type:level and level) and the "level" element is mandatory. What about the new
sentence?
--
Euler Taveira
EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
On Fri, Nov 21, 2025, at 11:13 AM, Euler Taveira wrote: > I think you missed my point here. As I said if your proposal will let us with > 2 > terminologies (backend type and process type) as shown above. We can debate > if > we (1) keep the current terminology (backend type), (2) use the proposed one > (process type) or (3) use a mixed variation (keep the SQL interface -- > backend_type column but change the description to "process type"). I wouldn't > like to break compatibility (pg_stat_activity changes tend to break a lot of > stuff) so I'm fine with (1) and (3). > After digesting it for a couple of days, I decided to adopt the terminology in commit dbf8cfb4f02e (process type) just for this patch. This discussion about changing "backend type" terminology in other parts belongs to another patch. >>> Good question. The current patch uses "backend" to B_INVALID (that's >>> exactly the >>> MyBackendType for postmaster -- see below). I think it is reasonable to >>> create a >>> new category "postmaster" and assign it to B_INVALID. >> >> I guess that would work, but I think it's inadequate. Maybe we could >> add a new value B_POSTMASTER and have postmaster switch to that as early >> as possible. Then anything that still has B_INVALID must necessarily be >> an improperly identified process. Users wouldn't assign a value to that >> one (the GUC wouldn't let you); instead those would always use the >> default value. Hopefully nobody would see that very often, or at all. >> > > I will create a separate patch for this suggestion. > After reflection, add B_POSTMASTER into BackendType / proctypelist.h is not a good idea. These data structures were designed to represent postmaster children. The child_process_kinds array (launch_backend.c) is assembled with proctypelist.h which means a function like postmaster_child_launch() could use one of its elements (e.g. B_POSTMASTER) to start a new child; that's awkward. Do you envision any issues to use B_INVALID for postmaster? (I wrote 0002 to minimize the windows that each child process has B_INVALID.) This new version contains the following changes: - fix variable assignment (Chao Li) - fix memory release order (Chao Li) - change category for B_INVALID (backend -> postmaster) (Alvaro) - rewrite documentation (Chao Li, Alvaro) - rename backend type to process type (Alvaro) - new patch (0002) that assigns MyBackendType as earlier as possible -- Euler Taveira EDB https://www.enterprisedb.com/From 5a6bfa1c9c6183eba8de5bbdeac43ea4ea5d8229 Mon Sep 17 00:00:00 2001 From: Euler Taveira Date: Tue, 4 Nov 2025 17:18:20 -0300 Subject: [PATCH v6 1/2] log_min_messages per process type Change log_min_messages from a single element to a comma-separated list of elements. Each element is type:level. The types are archiver, autovacuum (includes launcher and workers), backend, bgworker, bgwriter, checkpointer, ioworker, postmaster, syslogger, slotsyncworker, startup, walreceiver, walsender, walsummarizer and walwriter. A single log level should be part of this list and it is applied as a final step to the process types that were not informed. The old syntax (a single log level) is still accepted for backward compatibility. In this case, it means the informed log level is applied for all process types. The default log level is the same (WARNING) for all process types. --- doc/src/sgml/config.sgml | 42 +++- src/backend/commands/extension.c | 2 +- src/backend/commands/variable.c | 208 ++ src/backend/postmaster/launch_backend.c | 2 +- src/backend/utils/error/elog.c| 2 +- src/backend/utils/init/miscinit.c | 2 +- src/backend/utils/misc/guc_parameters.dat | 10 +- src/backend/utils/misc/guc_tables.c | 21 +- src/backend/utils/misc/postgresql.conf.sample | 2 + src/include/postmaster/proctypelist.h | 42 ++-- src/include/utils/guc.h | 6 +- src/include/utils/guc_hooks.h | 2 + src/test/regress/expected/guc.out | 54 + src/test/regress/sql/guc.sql | 18 ++ 14 files changed, 372 insertions(+), 41 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 023b3f03ba9..fba26aa746e 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -7063,7 +7063,7 @@ local0.*/var/log/postgresql - log_min_messages (enum) + log_min_messages (string) log_min_messages configuration parameter @@ -7072,14 +7072,38 @@ local0.*/var/log/postgresql Controls which message levels are written to the server log. -Valid values are DEBUG5, DEBUG4, -DEBUG3, DEBUG2, DEBUG1, -INFO, NOTICE, WARNING, -ERROR, LOG, FATAL, and -PANIC. Each level includes all the levels that -follow it. The later the level, the fewer messages are se
Re: log_min_messages per backend type
On Wed, Nov 19, 2025, at 7:44 AM, Alvaro Herrera wrote: > On 2025-Nov-18, Euler Taveira wrote: >> The "backend type" terminology is exposed. > > Something appearing in the source code does not equate it being exposed > to end users. Things are exposed when they are in the documentation, or > when the SQL interface requires you to use the term. So I don't think > the fact that BackendType appears in the code forces us to use that name > in the user-visible interface now. > It is *already* exposed. $ grep -B 3 -A 3 'backend type' doc/src/sgml/config.sgml The backend type corresponds to the column backend_type in the view pg_stat_activity, -- character count of the error position therein, location of the error in the PostgreSQL source code (if log_error_verbosity is set to verbose), application name, backend type, process ID of parallel group leader, and query id. Here is a sample table definition for storing CSV-format log output: $ grep -B 3 -A 3 'backend_type' doc/src/sgml/config.sgml The backend type corresponds to the column backend_type in the view pg_stat_activity, but additional types can appear -- query_pos integer, location text, application_name text, backend_type text, leader_pid integer, query_id bigint, PRIMARY KEY (session_id, session_line_num) -- Client application name backend_type string Type of backend $ psql -c "SELECT backend_type FROM pg_stat_activity" -d postgres backend_type -- client backend autovacuum launcher logical replication launcher io worker io worker io worker checkpointer background writer walwriter (9 rows) > In the glossary, we talk about "processes"; in the definitions there, > "backend" is one type of process. So in this list of "backend types" > that you want to introduce, what you really should be talking about is > "process types", where "backend" is one of the options. > >> It is even available in the >> pg_stat_activity view. I agree that "backend" is not a good name to define a >> Postgres process. I don't think we should be inconsistent only in this patch. >> Even if the proposal is to rename enum BackendType (I won't propose it as >> part >> of this patch), it would make some extension authors unhappy according to >> codesearch.debian.net. > > I don't think we should rename the BackendType enum. That's in the > source code, not in the documentation or the SQL interface, so we don't > need to care. > I think you missed my point here. As I said if your proposal will let us with 2 terminologies (backend type and process type) as shown above. We can debate if we (1) keep the current terminology (backend type), (2) use the proposed one (process type) or (3) use a mixed variation (keep the SQL interface -- backend_type column but change the description to "process type"). I wouldn't like to break compatibility (pg_stat_activity changes tend to break a lot of stuff) so I'm fine with (1) and (3). >> > I think the list of backend types is pretty hard to read. What do you >> > think about using >> > >> > to create a friendlier representation? >> >> I tried but didn't like the result. See the attached image. > > Well, I like it very much. The original is a solid wall of text, very > hard to read, where you have to squint hunting commas in order to > distinguish one item from the next. (Maybe you are young and have good > eyesight, but you won't be young forever.) In the screenshot you show, > the list of possible process types to use is nicely separated, which > makes it very easy to catch at a glance. Maybe remove "the table", > which is obviously inappropriate, and just say "Valid process types are > listed below, each corresponding to either postmaster, an auxiliary > process type or a backend". > I don't have a strong preference. One advantage of this suggestion is that it is visually easier to identify the types. > (Note your original wording says "a backend type, corresponding to [blah > blah] or a backend" which makes no sense -- how is a backend a type of > backend? It isn't. It's a type of process.) > I'm rewriting that paragraph. >> Good question. The current patch uses "backend" to B_INVALID (that's exactly >> the >> MyBackendType for postmaster -- see below). I think it is reasonable to >> create a >> new category "postmaster" and assign it to B_INVALID. > > I guess that would work, but I think it's inadequate. Maybe we could > add a new value B_POSTMASTER and have postmaster switch to that as early > as possible. Then anything that still has B_INVALID must necessarily be > an improperly identified process. Users wouldn't assign a value to that > one (the GUC wouldn't let you); instead those would always use the > default valu
Re: log_min_messages per backend type
On 2025-Nov-18, Euler Taveira wrote: > On Thu, Nov 6, 2025, at 1:01 PM, Alvaro Herrera wrote: > See miscadmin.h. > > /* > * MyBackendType indicates what kind of a backend this is. > * > * If you add entries, please also update the child_process_kinds array in > * launch_backend.c. > */ > typedef enum BackendType > > The "backend type" terminology is exposed. Something appearing in the source code does not equate it being exposed to end users. Things are exposed when they are in the documentation, or when the SQL interface requires you to use the term. So I don't think the fact that BackendType appears in the code forces us to use that name in the user-visible interface now. In the glossary, we talk about "processes"; in the definitions there, "backend" is one type of process. So in this list of "backend types" that you want to introduce, what you really should be talking about is "process types", where "backend" is one of the options. > It is even available in the > pg_stat_activity view. I agree that "backend" is not a good name to define a > Postgres process. I don't think we should be inconsistent only in this patch. > Even if the proposal is to rename enum BackendType (I won't propose it as part > of this patch), it would make some extension authors unhappy according to > codesearch.debian.net. I don't think we should rename the BackendType enum. That's in the source code, not in the documentation or the SQL interface, so we don't need to care. > > I think the list of backend types is pretty hard to read. What do you > > think about using > > > > to create a friendlier representation? > > I tried but didn't like the result. See the attached image. Well, I like it very much. The original is a solid wall of text, very hard to read, where you have to squint hunting commas in order to distinguish one item from the next. (Maybe you are young and have good eyesight, but you won't be young forever.) In the screenshot you show, the list of possible process types to use is nicely separated, which makes it very easy to catch at a glance. Maybe remove "the table", which is obviously inappropriate, and just say "Valid process types are listed below, each corresponding to either postmaster, an auxiliary process type or a backend". (Note your original wording says "a backend type, corresponding to [blah blah] or a backend" which makes no sense -- how is a backend a type of backend? It isn't. It's a type of process.) > You said table but it is a multi-column list; it doesn't contain a > header or borders. Right. You don't need a full-blown table here: this simple list is perfectly adequate. > Good question. The current patch uses "backend" to B_INVALID (that's exactly > the > MyBackendType for postmaster -- see below). I think it is reasonable to > create a > new category "postmaster" and assign it to B_INVALID. I guess that would work, but I think it's inadequate. Maybe we could add a new value B_POSTMASTER and have postmaster switch to that as early as possible. Then anything that still has B_INVALID must necessarily be an improperly identified process. Users wouldn't assign a value to that one (the GUC wouldn't let you); instead those would always use the default value. Hopefully nobody would see that very often, or at all. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
Re: log_min_messages per backend type
On Thu, Nov 6, 2025, at 1:01 PM, Alvaro Herrera wrote:
>
> I would use type:level rather than "backendtype".
> Also, the glossary says we have "auxiliary processes" and "backends", so
> from the user perspective, these types are not all backends, but instead
> process types.
>
Hasn't that ship already sailed? If your suggestion is limited to "type:level",
that's ok. I wouldn't like to use 2 terminologies ("process type" and "backend
type") in the documentation.
See miscadmin.h.
/*
* MyBackendType indicates what kind of a backend this is.
*
* If you add entries, please also update the child_process_kinds array in
* launch_backend.c.
*/
typedef enum BackendType
The "backend type" terminology is exposed. It is even available in the
pg_stat_activity view. I agree that "backend" is not a good name to define a
Postgres process. I don't think we should be inconsistent only in this patch.
Even if the proposal is to rename enum BackendType (I won't propose it as part
of this patch), it would make some extension authors unhappy according to
codesearch.debian.net.
> I think the list of backend types is pretty hard to read. What do you
> think about using
>
> to create a friendlier representation?
>
I tried but didn't like the result. See the attached image. You said table but
it is a multi-column list; it doesn't contain a header or borders. Reading this
message and Chao Li message, I realized the description is not good enough yet.
> So you would say something like "Valid types are listed in the table
> below, each corresponding to either postmaster, an auxiliary process
> type or a backend". (Eh, wait, you seem not to have "postmaster" in
> your list, what's up with that?)
>
Good question. The current patch uses "backend" to B_INVALID (that's exactly the
MyBackendType for postmaster -- see below). I think it is reasonable to create a
new category "postmaster" and assign it to B_INVALID. If, for some reason, a
process temporarily has MyBackendType equals to B_INVALID, it is ok to still
consider it a postmaster process.
$ ps aux | grep postgres
euler 56968 0.0 0.0 217144 29016 ?Ss 19:28 0:00
/c/pg/bin/postgres -D /c/pg/pgdata
euler 56969 0.0 0.0 217276 9948 ?Ss 19:28 0:00 postgres: io
worker 0
euler 56970 0.0 0.0 217276 7620 ?Ss 19:28 0:00 postgres: io
worker 1
euler 56971 0.0 0.0 217144 6408 ?Ss 19:28 0:00 postgres: io
worker 2
euler 56972 0.0 0.0 217276 8388 ?Ss 19:28 0:00 postgres:
checkpointer
euler 56973 0.0 0.0 217300 8744 ?Ss 19:28 0:00 postgres:
background writer
euler 56975 0.0 0.0 217276 11292 ?Ss 19:28 0:00 postgres:
walwriter
euler 56976 0.0 0.0 218724 9140 ?Ss 19:28 0:00 postgres:
autovacuum launcher
euler 56977 0.0 0.0 218724 9232 ?Ss 19:28 0:00 postgres:
logical replication launcher
euler 58717 0.0 0.0 6676 2232 pts/1S+ 19:39 0:00 grep
--color=auto postgres
$ for p in $(pgrep postgres); do echo "pid: $p" && gdb -q -batch -ex 'set
pagination off' -ex "attach $p" -ex 'p MyBackendType' -ex 'quit' 2> /dev/null;
done | grep -E '^\$1|pid'
pid: 56968
$1 = B_INVALID
pid: 56969
$1 = B_IO_WORKER
pid: 56970
$1 = B_IO_WORKER
pid: 56971
$1 = B_IO_WORKER
pid: 56972
$1 = B_CHECKPOINTER
pid: 56973
$1 = B_BG_WRITER
pid: 56975
$1 = B_WAL_WRITER
pid: 56976
$1 = B_AUTOVAC_LAUNCHER
pid: 56977
$1 = B_BG_WORKER
> (I'm not sure about making the log levels also a , because
> for that list the order matters, and if we have more than one column
> then the order is going to be ambiguous, and if we have just one column
> it's going to be too tall. But maybe it's not all that bad?)
>
+1.
--
Euler Taveira
EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
On 2025-Nov-06, Euler Taveira wrote: > +Valid values are a comma-separated list of > backendtype:level > +and a single level. The list allows it to use > +different levels per backend type. Only the single > level > +is mandatory (order does not matter) and it is assigned to the > backend > +types that are not specified in the list. > +Valid backendtype values are > archiver, > +autovacuum, backend, > +bgworker, bgwriter, > +checkpointer, ioworker, > +syslogger, slotsyncworker, > +startup, walreceiver, > +walsender, walsummarizer, and > +walwriter. > +Valid level values are DEBUG5, > +DEBUG4, DEBUG3, > DEBUG2, > +DEBUG1, INFO, > NOTICE, > +WARNING, ERROR, > LOG, > +FATAL, and PANIC. Each level > includes > +all the levels that follow it. The later the level, the fewer > messages are sent > +to the log. The default is WARNING for all > backend types. I would use type:level rather than "backendtype". Also, the glossary says we have "auxiliary processes" and "backends", so from the user perspective, these types are not all backends, but instead process types. I think the list of backend types is pretty hard to read. What do you think about using to create a friendlier representation? So you would say something like "Valid types are listed in the table below, each corresponding to either postmaster, an auxiliary process type or a backend". (Eh, wait, you seem not to have "postmaster" in your list, what's up with that?) (I'm not sure about making the log levels also a , because for that list the order matters, and if we have more than one column then the order is going to be ambiguous, and if we have just one column it's going to be too tall. But maybe it's not all that bad?) -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Re: log_min_messages per backend type
Hi Euler,
I just reviewed the patch and got a few comments.
> On Nov 6, 2025, at 21:09, Euler Taveira wrote:
>
> On Sun, Oct 5, 2025, at 11:18 AM, Euler Taveira wrote:
>> This new patch contains the following changes:
>>
>> - patch was rebased
>> - use commit dbf8cfb4f02
>> - use some GUC memory allocation functions
>> - avoid one memory allocation (suggested by Japin Li)
>> - rename backend type: logger -> syslogger
>> - adjust tests to increase test coverage
>> - improve documentation and comments to reflect the current state
>>
>
> Patch was rebased since commit fce7c73fba4 broke it. No modifications.
>
>
> --
> Euler Taveira
> EDB
> https://www.enterprisedb.com/
1 - variable.c
```
+ /* Initialize the array. */
+ memset(newlevel, WARNING, BACKEND_NUM_TYPES * sizeof(int));
```
I think this statement is wrong, because memset() writes bytes but integers, so
this statement will set very byte to WARNING, which should not be the
intention. You will need to use a loop to initialize every element of newlevel.
2 - variable.c
```
+ /* Parse string into list of identifiers. */
+ if (!SplitGUCList(rawstring, ',', &elemlist))
+ {
+ /* syntax error in list */
+ GUC_check_errdetail("List syntax is invalid.");
+ guc_free(rawstring);
+ list_free(elemlist);
+ return false;
+ }
```
Every element of elemlist points to a position of rawstring, so it’s better to
list_free(elemlist) first then guc_free(rawstring).
3 - launch_backend.c
```
static inline bool
should_output_to_server(int elevel)
{
- return is_log_level_output(elevel, log_min_messages);
+ return is_log_level_output(elevel, log_min_messages[MyBackendType]);
}
```
Is it possible that when this function is called, MyBackendType has not been
initialized? To be safe, maybe we can check if MyBackendType is 0 (B_INVALID),
then use the generic log_min_message.
4 - config.sgml
```
+Valid values are a comma-separated list of
backendtype:level
+and a single level. The list allows it to use
+different levels per backend type. Only the single
level
+is mandatory (order does not matter) and it is assigned to the backend
+types that are not specified in the list.
+Valid backendtype values are
archiver,
+autovacuum, backend,
+bgworker, bgwriter,
+checkpointer, ioworker,
+syslogger, slotsyncworker,
+startup, walreceiver,
+walsender, walsummarizer, and
+walwriter.
+Valid level values are DEBUG5,
+DEBUG4, DEBUG3,
DEBUG2,
+DEBUG1, INFO,
NOTICE,
+WARNING, ERROR,
LOG,
+FATAL, and PANIC. Each level
includes
+all the levels that follow it. The later the level, the fewer
messages are sent
+to the log. The default is WARNING for all backend
types.
+Note that LOG has a different rank here than in
```
* “Valid values are …”, here “are” usually mean both are needed, so maybe
change “are” to “can be”.
* It says “the single level is mandatory”, then why there is still a default
value?
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Re: log_min_messages per backend type
On Sun, Oct 5, 2025, at 11:18 AM, Euler Taveira wrote:
> This new patch contains the following changes:
>
> - patch was rebased
> - use commit dbf8cfb4f02
> - use some GUC memory allocation functions
> - avoid one memory allocation (suggested by Japin Li)
> - rename backend type: logger -> syslogger
> - adjust tests to increase test coverage
> - improve documentation and comments to reflect the current state
>
Patch was rebased since commit fce7c73fba4 broke it. No modifications.
--
Euler Taveira
EDB https://www.enterprisedb.com/From e457cc99c20f54d8e7e998104402e849ecf83c14 Mon Sep 17 00:00:00 2001
From: Euler Taveira
Date: Tue, 4 Nov 2025 17:18:20 -0300
Subject: [PATCH v5] log_min_messages per backend type
Change log_min_messages from a single element to a comma-separated list
of elements. Each element is backendtype:loglevel. The backendtype are
archiver, autovacuum (includes launcher and workers), backend, bgworker,
bgwriter, checkpointer, ioworker, syslogger, slotsyncworker, startup,
walreceiver, walsender, walsummarizer and walwriter. A single log level
should be part of this list and it is applied as a final step to the
backend types that were not informed.
The old syntax (a single log level) is still accepted for backward
compatibility. In this case, it means the informed log level is applied
for all backend types. The default log level is the same (WARNING) for
all backend types.
---
doc/src/sgml/config.sgml | 31 ++-
src/backend/commands/extension.c | 2 +-
src/backend/commands/variable.c | 205 ++
src/backend/postmaster/launch_backend.c | 2 +-
src/backend/utils/error/elog.c| 2 +-
src/backend/utils/init/miscinit.c | 2 +-
src/backend/utils/misc/guc_parameters.dat | 10 +-
src/backend/utils/misc/guc_tables.c | 21 +-
src/backend/utils/misc/postgresql.conf.sample | 2 +
src/include/postmaster/proctypelist.h | 38 ++--
src/include/utils/guc.h | 6 +-
src/include/utils/guc_hooks.h | 2 +
src/test/regress/expected/guc.out | 54 +
src/test/regress/sql/guc.sql | 18 ++
14 files changed, 356 insertions(+), 39 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d8a9f14b618..2ac1e65aa60 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -7053,7 +7053,7 @@ local0.*/var/log/postgresql
- log_min_messages (enum)
+ log_min_messages (string)
log_min_messages configuration parameter
@@ -7062,14 +7062,27 @@ local0.*/var/log/postgresql
Controls which message
levels are written to the server log.
-Valid values are DEBUG5, DEBUG4,
-DEBUG3, DEBUG2, DEBUG1,
-INFO, NOTICE, WARNING,
-ERROR, LOG, FATAL, and
-PANIC. Each level includes all the levels that
-follow it. The later the level, the fewer messages are sent
-to the log. The default is WARNING. Note that
-LOG has a different rank here than in
+Valid values are a comma-separated list of backendtype:level
+and a single level. The list allows it to use
+different levels per backend type. Only the single level
+is mandatory (order does not matter) and it is assigned to the backend
+types that are not specified in the list.
+Valid backendtype values are archiver,
+autovacuum, backend,
+bgworker, bgwriter,
+checkpointer, ioworker,
+syslogger, slotsyncworker,
+startup, walreceiver,
+walsender, walsummarizer, and
+walwriter.
+Valid level values are DEBUG5,
+DEBUG4, DEBUG3, DEBUG2,
+DEBUG1, INFO, NOTICE,
+WARNING, ERROR, LOG,
+FATAL, and PANIC. Each level includes
+all the levels that follow it. The later the level, the fewer messages are sent
+to the log. The default is WARNING for all backend types.
+Note that LOG has a different rank here than in
.
Only superusers and users with the appropriate SET
privilege can change this setting.
diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c
index 93ef1ad106f..81f7bc5e567 100644
--- a/src/backend/commands/extension.c
+++ b/src/backend/commands/extension.c
@@ -1143,7 +1143,7 @@ execute_extension_script(Oid extensionOid, ExtensionControlFile *control,
(void) set_config_option("client_min_messages", "warning",
PGC_USERSET, PGC_S_SESSION,
GUC_ACTION_SAVE, true, 0, false);
- if (log_min_messages < WARNING)
+ if (log_min_messages[MyBackendType] < WARNING)
(void) set_config_option_ext("log_min_messages", "warning",
PGC_SUSET, PGC_S_SESSION,
BOOTSTRAP_SUPERUSERID,
diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index
Re: log_min_messages per backend type
On Thu, Jul 31, 2025, at 8:34 PM, Japin Li wrote: > On Thu, 31 Jul 2025 at 18:51, Alvaro Herrera wrote: >> On 2025-Aug-01, Japin Li wrote: >> >>> If we set the log level for all backend types, I don't think a generic log >>> level is necessary. >> >> I don't understand what you mean by this. Can you elaborate? >> > For example: > > ALTER SYSTEM SET log_min_messages TO > 'archiver:info, autovacuum:info, backend:info, bgworker:info, > bgwriter:info, checkpointer:info, ioworker:info, logger:info, > slotsyncworker:info, startup:info, walreceiver:info, walsender:info, > walsummarizer:info, walwriter:info'; > > Given that we've set a log level for every backend type and > assigned[BACKEND_NUM_TYPES] is true, a generic level seems redundant. > The main reason I didn't consider this idea was that this GUC assignment will fail as soon as a new backend type is added. Restore a dump should work across major versions. > I think we can avoid memory allocation by using pg_strncasecmp(). > loglevel does not required a memory allocation but I didn't include the btype part because it complicates the error message that uses btype a few lines above. This new patch contains the following changes: - patch was rebased - use commit dbf8cfb4f02 - use some GUC memory allocation functions - avoid one memory allocation (suggested by Japin Li) - rename backend type: logger -> syslogger - adjust tests to increase test coverage - improve documentation and comments to reflect the current state -- Euler Taveira EDB https://www.enterprisedb.com/From 37a99059c8eaed5bece5d56530892edf348d2e67 Mon Sep 17 00:00:00 2001 From: Euler Taveira Date: Tue, 30 Sep 2025 10:59:25 -0300 Subject: [PATCH v4] log_min_messages per backend type Change log_min_messages from a single element to a comma-separated list of elements. Each element is backendtype:loglevel. The backendtype are archiver, autovacuum (includes launcher and workers), backend, bgworker, bgwriter, checkpointer, ioworker, syslogger, slotsyncworker, startup, walreceiver, walsender, walsummarizer and walwriter. A single log level should be part of this list and it is applied as a final step to the backend types that were not informed. The old syntax (a single log level) is still accepted for backward compatibility. In this case, it means the informed log level is applied for all backend types. The default log level is the same (WARNING) for all backend types. --- doc/src/sgml/config.sgml | 31 ++- src/backend/commands/extension.c | 2 +- src/backend/commands/variable.c | 205 ++ src/backend/postmaster/launch_backend.c | 2 +- src/backend/utils/error/elog.c| 2 +- src/backend/utils/init/miscinit.c | 2 +- src/backend/utils/misc/guc_parameters.dat | 18 +- src/backend/utils/misc/guc_tables.c | 25 ++- src/backend/utils/misc/postgresql.conf.sample | 2 + src/include/postmaster/proctypelist.h | 38 ++-- src/include/utils/guc.h | 2 +- src/include/utils/guc_hooks.h | 2 + src/include/utils/guc_tables.h| 4 + src/test/regress/expected/guc.out | 54 + src/test/regress/sql/guc.sql | 18 ++ 15 files changed, 364 insertions(+), 43 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index e9b420f3ddb..b31d5875838 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -7022,7 +7022,7 @@ local0.*/var/log/postgresql - log_min_messages (enum) + log_min_messages (string) log_min_messages configuration parameter @@ -7031,14 +7031,27 @@ local0.*/var/log/postgresql Controls which message levels are written to the server log. -Valid values are DEBUG5, DEBUG4, -DEBUG3, DEBUG2, DEBUG1, -INFO, NOTICE, WARNING, -ERROR, LOG, FATAL, and -PANIC. Each level includes all the levels that -follow it. The later the level, the fewer messages are sent -to the log. The default is WARNING. Note that -LOG has a different rank here than in +Valid values are a comma-separated list of backendtype:level +and a single level. The list allows it to use +different levels per backend type. Only the single level +is mandatory (order does not matter) and it is assigned to the backend +types that are not specified in the list. +Valid backendtype values are archiver, +autovacuum, backend, +bgworker, bgwriter, +checkpointer, ioworker, +syslogger, slotsyncworker, +startup, walreceiver, +walsender, walsummarizer, and +walwriter. +Valid level values are DEBUG5, +DEBUG4, DEBUG3, DEBUG2, +DEBUG1, INFO, NOTICE, +WARNING, ERROR, LOG, +FATAL, and PANIC. Each level includes
Re: log_min_messages per backend type
On Thu, Jul 31, 2025 at 11:19:48AM -0300, Euler Taveira wrote:
> On Thu, Mar 6, 2025, at 10:33 AM, Andres Freund wrote:
> > Huh, the startup process is among the most crucial things to monitor?
> >
>
> Good point. Fixed.
>
> After collecting some suggestions, I'm attaching a new patch contains the
> following changes:
>
> - patch was rebased
> - include Alvaro's patch (v2-0001) [1] as a basis for this patch
> - add ioworker as new backend type
> - add startup as new backend type per Andres suggestion
> - small changes into documentation
>
> > I don't know what I think about the whole patch, but I do want to voice
> > *strong* opposition to duplicating a list of all backend types into multiple
> > places. It's already painfull enough to add a new backend type, without
> > having
> > to pointlessly go around and manually add a new backend type to mulltiple
> > arrays that have completely predictable content.
> >
>
> I'm including Alvaro's patch as is just to make the CF bot happy and to
> illustrate how it would be if we adopt his solution to centralize the list of
> backend types. I think Alvaro's proposal overcomes the objection [2], right?
>
I think we can avoid memory allocation by using pg_strncasecmp().
diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index 5c769dd7bcc..f854b2fac93 100644
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -1343,14 +1343,10 @@ check_log_min_messages(char **newval, void **extra,
GucSource source)
}
else
{
- char *loglevel;
- char *btype;
- boolfound = false;
- btype = palloc((sep - tok) + 1);
- memcpy(btype, tok, sep - tok);
- btype[sep - tok] = '\0';
- loglevel = pstrdup(sep + 1);
+ char *btype = tok;
+ char *loglevel = sep + 1;
+ boolfound = false;
/* Is the log level valid? */
for (entry = server_message_level_options; entry &&
entry->name; entry++)
@@ -1377,7 +1373,7 @@ check_log_min_messages(char **newval, void **extra,
GucSource source)
found = false;
for (int i = 0; i < BACKEND_NUM_TYPES; i++)
{
- if
(pg_strcasecmp(log_min_messages_backend_types[i], btype) == 0)
+ if
(pg_strncasecmp(log_min_messages_backend_types[i], btype, sep - tok) == 0)
{
/* Reject duplicates for a backend
type. */
if (assigned[i])
--
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.
Re: log_min_messages per backend type
On Thu, 31 Jul 2025 at 18:51, Alvaro Herrera wrote: > On 2025-Aug-01, Japin Li wrote: > >> If we set the log level for all backend types, I don't think a generic log >> level is necessary. > > I don't understand what you mean by this. Can you elaborate? > For example: ALTER SYSTEM SET log_min_messages TO 'archiver:info, autovacuum:info, backend:info, bgworker:info, bgwriter:info, checkpointer:info, ioworker:info, logger:info, slotsyncworker:info, startup:info, walreceiver:info, walsender:info, walsummarizer:info, walwriter:info'; Given that we've set a log level for every backend type and assigned[BACKEND_NUM_TYPES] is true, a generic level seems redundant. -- Regards, Japin Li ChengDu WenWu Information Technology Co., Ltd.
Re: log_min_messages per backend type
On 2025-Aug-01, Japin Li wrote: > If we set the log level for all backend types, I don't think a generic log > level is necessary. I don't understand what you mean by this. Can you elaborate? -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "If it is not right, do not do it. If it is not true, do not say it." (Marcus Aurelius, Meditations)
Re: log_min_messages per backend type
On Thu, 31 Jul 2025 at 11:19, "Euler Taveira" wrote: > On Thu, Mar 6, 2025, at 10:33 AM, Andres Freund wrote: >> Huh, the startup process is among the most crucial things to monitor? >> > > Good point. Fixed. > > After collecting some suggestions, I'm attaching a new patch contains the > following changes: > > - patch was rebased > - include Alvaro's patch (v2-0001) [1] as a basis for this patch > - add ioworker as new backend type > - add startup as new backend type per Andres suggestion > - small changes into documentation > >> I don't know what I think about the whole patch, but I do want to voice >> *strong* opposition to duplicating a list of all backend types into multiple >> places. It's already painfull enough to add a new backend type, without >> having >> to pointlessly go around and manually add a new backend type to mulltiple >> arrays that have completely predictable content. >> > > I'm including Alvaro's patch as is just to make the CF bot happy and to > illustrate how it would be if we adopt his solution to centralize the list of > backend types. I think Alvaro's proposal overcomes the objection [2], right? > If we set the log level for all backend types, I don't think a generic log level is necessary. -- Regards, Japin Li ChengDu WenWu Information Technology Co., Ltd.
Re: log_min_messages per backend type
On Thu, Mar 6, 2025, at 10:33 AM, Andres Freund wrote: > Huh, the startup process is among the most crucial things to monitor? > Good point. Fixed. After collecting some suggestions, I'm attaching a new patch contains the following changes: - patch was rebased - include Alvaro's patch (v2-0001) [1] as a basis for this patch - add ioworker as new backend type - add startup as new backend type per Andres suggestion - small changes into documentation > I don't know what I think about the whole patch, but I do want to voice > *strong* opposition to duplicating a list of all backend types into multiple > places. It's already painfull enough to add a new backend type, without having > to pointlessly go around and manually add a new backend type to mulltiple > arrays that have completely predictable content. > I'm including Alvaro's patch as is just to make the CF bot happy and to illustrate how it would be if we adopt his solution to centralize the list of backend types. I think Alvaro's proposal overcomes the objection [2], right? [1] https://www.postgresql.org/message-id/[email protected] [2] https://www.postgresql.org/message-id/y5tgui75jrcj6mm5nmoq4yqwage2432akx4kp2ogtcnim3wskx@2ipmtfi4qvpi -- Euler Taveira EDB https://www.enterprisedb.com/From ec409dada269cf54b9bce16cae473a46b2400598 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Herrera?= Date: Tue, 15 Jul 2025 18:19:27 +0200 Subject: [PATCH v3 1/2] Create a separate file listing backend types Use our established coding pattern to reduce maintenance pain when adding other per-process-type characteristics. Like PG_KEYWORD, PG_CMDTAG, PG_RMGR. --- src/backend/postmaster/launch_backend.c | 32 ++ src/backend/utils/init/miscinit.c | 59 ++--- src/include/postmaster/proctypelist.h | 50 + 3 files changed, 58 insertions(+), 83 deletions(-) create mode 100644 src/include/postmaster/proctypelist.h diff --git a/src/backend/postmaster/launch_backend.c b/src/backend/postmaster/launch_backend.c index bf6b55ee830..8b2f1a0cf41 100644 --- a/src/backend/postmaster/launch_backend.c +++ b/src/backend/postmaster/launch_backend.c @@ -177,34 +177,10 @@ typedef struct } child_process_kind; static child_process_kind child_process_kinds[] = { - [B_INVALID] = {"invalid", NULL, false}, - - [B_BACKEND] = {"backend", BackendMain, true}, - [B_DEAD_END_BACKEND] = {"dead-end backend", BackendMain, true}, - [B_AUTOVAC_LAUNCHER] = {"autovacuum launcher", AutoVacLauncherMain, true}, - [B_AUTOVAC_WORKER] = {"autovacuum worker", AutoVacWorkerMain, true}, - [B_BG_WORKER] = {"bgworker", BackgroundWorkerMain, true}, - - /* - * WAL senders start their life as regular backend processes, and change - * their type after authenticating the client for replication. We list it - * here for PostmasterChildName() but cannot launch them directly. - */ - [B_WAL_SENDER] = {"wal sender", NULL, true}, - [B_SLOTSYNC_WORKER] = {"slot sync worker", ReplSlotSyncWorkerMain, true}, - - [B_STANDALONE_BACKEND] = {"standalone backend", NULL, false}, - - [B_ARCHIVER] = {"archiver", PgArchiverMain, true}, - [B_BG_WRITER] = {"bgwriter", BackgroundWriterMain, true}, - [B_CHECKPOINTER] = {"checkpointer", CheckpointerMain, true}, - [B_IO_WORKER] = {"io_worker", IoWorkerMain, true}, - [B_STARTUP] = {"startup", StartupProcessMain, true}, - [B_WAL_RECEIVER] = {"wal_receiver", WalReceiverMain, true}, - [B_WAL_SUMMARIZER] = {"wal_summarizer", WalSummarizerMain, true}, - [B_WAL_WRITER] = {"wal_writer", WalWriterMain, true}, - - [B_LOGGER] = {"syslogger", SysLoggerMain, false}, +#define PG_PROCTYPE(bktype, description, main_func, shmem_attach) \ + [bktype] = {description, main_func, shmem_attach}, +#include "postmaster/proctypelist.h" +#undef PG_PROCTYPE }; const char * diff --git a/src/backend/utils/init/miscinit.c b/src/backend/utils/init/miscinit.c index 43b4dbccc3d..dec220a61f5 100644 --- a/src/backend/utils/init/miscinit.c +++ b/src/backend/utils/init/miscinit.c @@ -266,62 +266,11 @@ GetBackendTypeDesc(BackendType backendType) switch (backendType) { - case B_INVALID: - backendDesc = gettext_noop("not initialized"); - break; - case B_ARCHIVER: - backendDesc = gettext_noop("archiver"); - break; - case B_AUTOVAC_LAUNCHER: - backendDesc = gettext_noop("autovacuum launcher"); - break; - case B_AUTOVAC_WORKER: - backendDesc = gettext_noop("autovacuum worker"); - break; - case B_BACKEND: - backendDesc = gettext_noop("client backend"); - break; - case B_DEAD_END_BACKEND: - backendDesc = gettext_noop("dead-end client backend"); - break; - case B_BG_WORKER: - backendDesc = gettext_noop("background worker"); - break; - case B_BG_WRITER: - backendDesc = gettext_noop("background writer"); - break; - case B_CHECKPOINTER: - backendDesc = gettext_noop("checkpointer"); - break; - case B_IO_WORKER: - backendDesc = gettext_noop("io worker"); - break; - case B_LOGGER:
Re: log_min_messages per backend type
On Wed, Mar 5, 2025, at 1:40 PM, Andrew Dunstan wrote: > Just bikeshedding a bit ... > > I'm not mad keen on this design. I think the value should be either a single > setting like "WARNING" or a set of type:setting pairs. I agree that "all" is > a bad name, but I think "default" would make sense. > One of my main concerns was a clear interface. I think "default" is less confusing than "all". Your suggestion about single or list is aligned with what Alvaro suggested. IIUC you are suggesting default:loglevel only if it is part of the list; the single loglevel shouldn't contain the backend type to keep the backward compatibility. The advantage of your proposal is that it make it clear what the fallback log level is. However, someone could be confused asking if the "default" is a valid backend type and if there is a difference between WARNING and default:WARNING (both is a fallback for non-specified backend type elements). -- Euler Taveira EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
Hi, > > On 2025-03-04 Tu 7:33 PM, Euler Taveira wrote: >>> I think it should be acceptable to configure one global setting with >>> exceptions for particular backend types: >>> >>> log_min_messages = WARNING, autovacuum:DEBUG1 >>> >>> Right now I think the code only accepts the unadorned log level if >>> there >>> are no other items in the list. I think the proposal downthread is to >>> use the keyword ALL for this, >>> >>> log_min_messages = all:WARNING, autovacuum:DEBUG1 # I don't >>> like this >>> >>> but I think it's inferior, because then "all" is not really "all", >>> and I >>> think it would be different if I had said >>> >>> log_min_messages = autovacuum:DEBUG1, all:WARNING # I don't >>> like this >>> >>> because it looks like the "all" entry should override the one I set >>> for >>> autovacuum before, which frankly would not make sense to me. >> >> Good point. After reflection, I agree that "all" is not a good keyword. >> This patch turns backend type as optional so WARNING means apply this >> log level as a final step to the backend types that are not >> specified in >> the list. >> >>> So I think these two lines, >>> >>> log_min_messages = WARNING, autovacuum:DEBUG1 >>> log_min_messages = autovacuum:DEBUG1, WARNING >>> >>> should behave identically and mean "set the level for autovacuum to >>> DEBUG1, and to any other backend type to WARNING. >> >> Done. > > > Just bikeshedding a bit ... > > I'm not mad keen on this design. I think the value should be either a > single setting like "WARNING" or a set of type:setting pairs. I agree > that "all" is a bad name, but I think "default" would make sense. > > I can live with it but I think this just looks a bit odd. > Just bringing some thoughts about it... How about using something like *:WARNING? I'm not sure if it could also be confusing as the "all" keyword, but I think it could also be interpreted as "anything else use WARNING". -- Matheus Alcantara
Re: log_min_messages per backend type
On Wed, Mar 5, 2025, at 11:53 PM, Fujii Masao wrote: > On 2025/03/05 9:33, Euler Taveira wrote: > >> > +Valid BACKENDTYPE values are > >> > ARCHIVER, > >> > +AUTOVACUUM, BACKEND, > >> > +BGWORKER, BGWRITER, > >> > +CHECKPOINTER, LOGGER, > >> > +SLOTSYNCWORKER, > >> > WALRECEIVER, > >> > +WALSENDER, WALSUMMARIZER, > >> > and > >> > +WALWRITER. > > What about postmaster? It is B_INVALID that is currently mapped to "backend". This state is used as an initial phase for the child process. There might be messages before MyBackendType is assigned (see ProcessStartupPacket, for example). Hence, I refrain to create a special backend type for postmaster. Should we map it to generic log level instead of backend? > For parallel workers launched for parallel queries, should they follow > the backend's log level or the background worker's? Since they operate > as part of a parallel query executed by a backend, it seems more logical > for them to follow the backend's setting. Since we are using enum BackendType and there is no special entry for parallel query processes. I'm afraid that introducing conditional logic for checking special cases like the bgw_type for parallel queries or MyProcPid == PostmasterPid might slowdown that code path. (See that should_output_to_server is an inline function.) I will run some tests to see if there is a considerable impact. > + [B_CHECKPOINTER] = "checkpointer", > + [B_STARTUP] = "backend", /* XXX same as backend? */ > > I like the idea of allowing log levels to be set per process. > There were times I wanted to use debug5 specifically for > the startup process when troubleshooting WAL replay. It would be > helpful to distinguish the startup process from a regular backend, > so we can set its log level independently. Although startup process is mapped to backend (hence, the XXX), we can certainly create a separate backend type for it. -- Euler Taveira EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
Hi,
On 2025-03-04 21:33:39 -0300, Euler Taveira wrote:
> +/*
> + * This must match enum BackendType! It should be static, but
> + * commands/variable.c needs to get at this.
> + */
> +int log_min_messages[] = {
> + [B_INVALID] = WARNING,
> + [B_BACKEND] = WARNING,
> + [B_DEAD_END_BACKEND] = WARNING,
> + [B_AUTOVAC_LAUNCHER] = WARNING,
> + [B_AUTOVAC_WORKER] = WARNING,
> + [B_BG_WORKER] = WARNING,
> + [B_WAL_SENDER] = WARNING,
> + [B_SLOTSYNC_WORKER] = WARNING,
> + [B_STANDALONE_BACKEND] = WARNING,
> + [B_ARCHIVER] = WARNING,
> + [B_BG_WRITER] = WARNING,
> + [B_CHECKPOINTER] = WARNING,
> + [B_STARTUP] = WARNING,
> + [B_WAL_RECEIVER] = WARNING,
> + [B_WAL_SUMMARIZER] = WARNING,
> + [B_WAL_WRITER] = WARNING,
> + [B_LOGGER] = WARNING,
> +};
> +StaticAssertDecl(lengthof(log_min_messages) == BACKEND_NUM_TYPES,
> + "array length mismatch");
> +
> +/*
> + * This must match enum BackendType! It might be in commands/variable.c but
> for
> + * convenience it is near log_min_messages.
> + */
> +const char *const log_min_messages_backend_types[] = {
> + [B_INVALID] = "backend",/* XXX same as backend? */
> + [B_BACKEND] = "backend",
> + [B_DEAD_END_BACKEND] = "backend", /* XXX same as backend? */
> + [B_AUTOVAC_LAUNCHER] = "autovacuum",
> + [B_AUTOVAC_WORKER] = "autovacuum",
> + [B_BG_WORKER] = "bgworker",
> + [B_WAL_SENDER] = "walsender",
> + [B_SLOTSYNC_WORKER] = "slotsyncworker",
> + [B_STANDALONE_BACKEND] = "backend", /* XXX same as backend? */
> + [B_ARCHIVER] = "archiver",
> + [B_BG_WRITER] = "bgwriter",
> + [B_CHECKPOINTER] = "checkpointer",
> + [B_STARTUP] = "backend",/* XXX same as backend? */
Huh, the startup process is among the most crucial things to monitor?
> + [B_WAL_RECEIVER] = "walreceiver",
> + [B_WAL_SUMMARIZER] = "walsummarizer",
> + [B_WAL_WRITER] = "walwriter",
> + [B_LOGGER] = "logger",
> +};
> +
> +StaticAssertDecl(lengthof(log_min_messages_backend_types) ==
> BACKEND_NUM_TYPES,
> + "array length mismatch");
> +
I don't know what I think about the whole patch, but I do want to voice
*strong* opposition to duplicating a list of all backend types into multiple
places. It's already painfull enough to add a new backend type, without having
to pointlessly go around and manually add a new backend type to mulltiple
arrays that have completely predictable content.
Greetings,
Andres Freund
Re: log_min_messages per backend type
On 2025/03/05 9:33, Euler Taveira wrote: > + Valid BACKENDTYPE values are ARCHIVER, > + AUTOVACUUM, BACKEND, > + BGWORKER, BGWRITER, > + CHECKPOINTER, LOGGER, > + SLOTSYNCWORKER, WALRECEIVER, > + WALSENDER, WALSUMMARIZER, and > + WALWRITER. What about postmaster? For parallel workers launched for parallel queries, should they follow the backend's log level or the background worker's? Since they operate as part of a parallel query executed by a backend, it seems more logical for them to follow the backend's setting. + [B_CHECKPOINTER] = "checkpointer", + [B_STARTUP] = "backend", /* XXX same as backend? */ I like the idea of allowing log levels to be set per process. There were times I wanted to use debug5 specifically for the startup process when troubleshooting WAL replay. It would be helpful to distinguish the startup process from a regular backend, so we can set its log level independently. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Re: log_min_messages per backend type
On 2025-03-04 Tu 7:33 PM, Euler Taveira wrote: I think it should be acceptable to configure one global setting with exceptions for particular backend types: log_min_messages = WARNING, autovacuum:DEBUG1 Right now I think the code only accepts the unadorned log level if there are no other items in the list. I think the proposal downthread is to use the keyword ALL for this, log_min_messages = all:WARNING, autovacuum:DEBUG1 # I don't like this but I think it's inferior, because then "all" is not really "all", and I think it would be different if I had said log_min_messages = autovacuum:DEBUG1, all:WARNING # I don't like this because it looks like the "all" entry should override the one I set for autovacuum before, which frankly would not make sense to me. Good point. After reflection, I agree that "all" is not a good keyword. This patch turns backend type as optional so WARNING means apply this log level as a final step to the backend types that are not specified in the list. So I think these two lines, log_min_messages = WARNING, autovacuum:DEBUG1 log_min_messages = autovacuum:DEBUG1, WARNING should behave identically and mean "set the level for autovacuum to DEBUG1, and to any other backend type to WARNING. Done. Just bikeshedding a bit ... I'm not mad keen on this design. I think the value should be either a single setting like "WARNING" or a set of type:setting pairs. I agree that "all" is a bad name, but I think "default" would make sense. I can live with it but I think this just looks a bit odd. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com
Re: log_min_messages per backend type
On Wed, Feb 5, 2025, at 3:51 PM, Álvaro Herrera wrote: > On 2024-Dec-17, Euler Taveira wrote: > > > Sometimes you need to inspect some debug messages from autovacuum worker but > > you cannot apply the same setting for backends (that could rapidly fill the > > log > > file). This proposal aims to change log_min_messages to have different log > > levels depending on which backend type the message comes from. > > > > The syntax was changed from enum to string and it accepts a list of > > elements. > > > > Instead of enum, it now accepts a comma-separated list of elements (string). > > Each element is LOGLEVEL:BACKENDTYPE. > > This format seems unintuitive. I would have thought you do it the other > way around, "backendtype:loglevel" ... that seems more natural because > it's like assigning the 'loglevel' value to the 'backendtype' element. > SET log_min_messages TO 'checkpointer:debug2, autovacuum:debug1'; Alvaro, thanks for your feedback. Your suggestion makes sense to me. > I dislike the array of names in variable.c. We already have an array in > launch_backend.c (child_process_kinds), plus GetBackendTypeDesc in > miscinit.c. Maybe not for this patch to clean up though. I thought about using child_process_kinds but two details made me give up on the idea: (a) multiple names per backend type (for example, B_BACKEND, B_DEAD_END_BACKEND, B_STANDALONE_BACKEND) and (b) spaces into names. Maybe we should have a group into child_process_kinds but as you said it seems material for another patch. > I think it should be acceptable to configure one global setting with > exceptions for particular backend types: > > log_min_messages = WARNING, autovacuum:DEBUG1 > > Right now I think the code only accepts the unadorned log level if there > are no other items in the list. I think the proposal downthread is to > use the keyword ALL for this, > > log_min_messages = all:WARNING, autovacuum:DEBUG1 # I don't like this > > but I think it's inferior, because then "all" is not really "all", and I > think it would be different if I had said > > log_min_messages = autovacuum:DEBUG1, all:WARNING # I don't like this > > because it looks like the "all" entry should override the one I set for > autovacuum before, which frankly would not make sense to me. Good point. After reflection, I agree that "all" is not a good keyword. This patch turns backend type as optional so WARNING means apply this log level as a final step to the backend types that are not specified in the list. > So I think these two lines, > > log_min_messages = WARNING, autovacuum:DEBUG1 > log_min_messages = autovacuum:DEBUG1, WARNING > > should behave identically and mean "set the level for autovacuum to > DEBUG1, and to any other backend type to WARNING. Done. > Also, I think it'd be better to reject duplicates in the list. Right > now it looks like the last entry for one backend type overrides prior > ones. I mean > > log_min_messages = autovacuum:DEBUG1, autovacuum:ERROR > > would set autovacuum to error, but that might be mistake prone if your > string is long. So implementation-wise I suggest to initialize the > whole newlogminmsgs array to -1, then scan the list of entries (saving > an entry without backend type as the one to use later and) setting every > backend type to the number specified; if we see trying to set a value > that's already different from -1, throw error. After scanning the whole > log_min_messages array, we scan the newlogminmsgs and set any entries > that are still -1 to the value that we saved before. > > > The new code in variable.c should be before the /* DATESTYLE */ comment > rather than at the end of the file. It was added into the MISCELLANEOUS section. > > You still have many XXX comments. Also, postgresql.conf should list the > valid values for backendtype, as well as show an example of a valid > setting. Please don't use ALLCAPS backend types in the docs, this looks > ugly: > > > +Valid BACKENDTYPE values are > > ARCHIVER, > > +AUTOVACUUM, BACKEND, > > +BGWORKER, BGWRITER, > > +CHECKPOINTER, LOGGER, > > +SLOTSYNCWORKER, WALRECEIVER, > > +WALSENDER, WALSUMMARIZER, and > > +WALWRITER. Done. Just to recap what was changed: - patch was rebased - backend type is optional and means all unspecified backend types - generic log level (without backend type) is mandatory and the order it ppears is not important (it is applied for the remaining backend types) - fix Windows build - new tests to cover the changes -- Euler Taveira EDB https://www.enterprisedb.com/ From 0640ddb6e5510f1b600982331490188d20bfa7e9 Mon Sep 17 00:00:00 2001 From: Euler Taveira Date: Mon, 11 Dec 2023 17:24:50 -0300 Subject: [PATCH v2] log_min_messages per backend type Change log_min_messages from a single element to a comma-separated list of elements. Each element is backendtype:loglevel. The backendtype are archiver, autovacuum (includes launcher and wo
Re: log_min_messages per backend type
Hello Euler, On 2024-Dec-17, Euler Taveira wrote: > Sometimes you need to inspect some debug messages from autovacuum worker but > you cannot apply the same setting for backends (that could rapidly fill the > log > file). This proposal aims to change log_min_messages to have different log > levels depending on which backend type the message comes from. > > The syntax was changed from enum to string and it accepts a list of elements. > > Instead of enum, it now accepts a comma-separated list of elements (string). > Each element is LOGLEVEL:BACKENDTYPE. This format seems unintuitive. I would have thought you do it the other way around, "backendtype:loglevel" ... that seems more natural because it's like assigning the 'loglevel' value to the 'backendtype' element. SET log_min_messages TO 'checkpointer:debug2, autovacuum:debug1'; I dislike the array of names in variable.c. We already have an array in launch_backend.c (child_process_kinds), plus GetBackendTypeDesc in miscinit.c. Maybe not for this patch to clean up though. I think it should be acceptable to configure one global setting with exceptions for particular backend types: log_min_messages = WARNING, autovacuum:DEBUG1 Right now I think the code only accepts the unadorned log level if there are no other items in the list. I think the proposal downthread is to use the keyword ALL for this, log_min_messages = all:WARNING, autovacuum:DEBUG1 # I don't like this but I think it's inferior, because then "all" is not really "all", and I think it would be different if I had said log_min_messages = autovacuum:DEBUG1, all:WARNING # I don't like this because it looks like the "all" entry should override the one I set for autovacuum before, which frankly would not make sense to me. So I think these two lines, log_min_messages = WARNING, autovacuum:DEBUG1 log_min_messages = autovacuum:DEBUG1, WARNING should behave identically and mean "set the level for autovacuum to DEBUG1, and to any other backend type to WARNING. Also, I think it'd be better to reject duplicates in the list. Right now it looks like the last entry for one backend type overrides prior ones. I mean log_min_messages = autovacuum:DEBUG1, autovacuum:ERROR would set autovacuum to error, but that might be mistake prone if your string is long. So implementation-wise I suggest to initialize the whole newlogminmsgs array to -1, then scan the list of entries (saving an entry without backend type as the one to use later and) setting every backend type to the number specified; if we see trying to set a value that's already different from -1, throw error. After scanning the whole log_min_messages array, we scan the newlogminmsgs and set any entries that are still -1 to the value that we saved before. The new code in variable.c should be before the /* DATESTYLE */ comment rather than at the end of the file. You still have many XXX comments. Also, postgresql.conf should list the valid values for backendtype, as well as show an example of a valid setting. Please don't use ALLCAPS backend types in the docs, this looks ugly: > +Valid BACKENDTYPE values are > ARCHIVER, > +AUTOVACUUM, BACKEND, > +BGWORKER, BGWRITER, > +CHECKPOINTER, LOGGER, > +SLOTSYNCWORKER, WALRECEIVER, > +WALSENDER, WALSUMMARIZER, and > +WALWRITER. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "No necesitamos banderas No reconocemos fronteras" (Jorge González)
Re: log_min_messages per backend type
On Thu, Dec 19, 2024, at 1:13 AM, Kirill Reshke wrote: > Hi! Looks like a sane proposal. Correct me if I'm wrong, but with your > patch it is not possible to configure something like "everybody ERROR, > but autovac DEBUG5"? I mean, > set log_min_messages to 'ERROR:default, DEBUG5:autovacuum' (not > specifying all possible cases?) > No. Good point. I forgot to mention that ALL as backend type could be added. -- Euler Taveira EDB https://www.enterprisedb.com/
Re: log_min_messages per backend type
On Wed, 18 Dec 2024 at 00:15, Euler Taveira wrote: > > Hi, > > Sometimes you need to inspect some debug messages from autovacuum worker but > you cannot apply the same setting for backends (that could rapidly fill the > log > file). This proposal aims to change log_min_messages to have different log > levels depending on which backend type the message comes from. Hi! Looks like a sane proposal. Correct me if I'm wrong, but with your patch it is not possible to configure something like "everybody ERROR, but autovac DEBUG5"? I mean, set log_min_messages to 'ERROR:default, DEBUG5:autovacuum' (not specifying all possible cases?)
