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" <alvherre(at)alvh(dot)no-ip(dot)org&gt;;
发送时间:&nbsp;2025年12月10日(星期三) 凌晨2:24
收件人:&nbsp;"Euler Taveira"<euler(at)eulerto(dot)com&gt;;
抄送:&nbsp;"japin"<japinli(at)hotmail(dot)com&gt;;"Andres Freund"<andres(at)anarazel(dot)de&gt;;"pgsql-hackers"<pgsql-hackers(at)lists(dot)postgresql(dot)org&gt;;"Chao Li"<li(dot)evan(dot)chao(at)gmail(dot)com&gt;;
主题:&nbsp;Re: log_min_messages per backend type

On 2025-Dec-09, Alvaro Herrera wrote:

&gt; So here's your v6 again with those fixes as 0003 -- let's see what CI
&gt; thinks of this.&nbsp; I haven't looked at your doc changes yet.

This passed CI, so I have marked it as Ready for Committer.&nbsp; 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.&nbsp; 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):

&nbsp; 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.&nbsp; I think it
should rather be

&nbsp; 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 Herrera&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; Breisgau, Deutschland&nbsp; —&nbsp; https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming"&nbsp; (A. Stepanov)