Re: log_min_messages per backend type
Euler Taveira <euler@eulerto.com>
From: "Euler Taveira" <euler@eulerto.com>
To: "Alvaro Herrera" <alvherre@alvh.no-ip.org>
Cc: japin <japinli@hotmail.com>, "Andres Freund" <andres@anarazel.de>,
pgsql-hackers@lists.postgresql.org, "Chao Li" <li.evan.chao@gmail.com>
Date: 2026-01-15T16:07:26Z
Lists: pgsql-hackers
Attachments
- v8-0001-log_min_messages-per-process-type.patch (text/x-patch) patch v8-0001
- v8-0002-Assign-backend-type-earlier.patch (text/x-patch) patch v8-0002
- v8-0003-fixup-log_min_messages-per-process-type.patch (text/x-patch) patch v8-0003
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/1130A10B-E7AE-49F3-9E13-2CD69B3F9DFD@gmail.com
--
Euler Taveira
EDB https://www.enterprisedb.com/
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Cleanup for log_min_messages changes in 38e0190ced71
- 1efdd7cc630a 19 (unreleased) landed
-
Allow log_min_messages to be set per process type
- 38e0190ced71 19 (unreleased) landed
-
Assign "backend" type earlier during process start-up
- 0c8e082fba8d 19 (unreleased) landed
-
Use integer backend type when exec'ing a postmaster child
- f1cd34f95272 19 (unreleased) landed
-
Sort guc_parameters.dat alphabetically by name
- fce7c73fba4e 19 (unreleased) cited
-
Create a separate file listing backend types
- dbf8cfb4f02e 19 (unreleased) cited
-
Replace postmaster.c's own backend type codes with BackendType
- 18d67a8d7d30 18.0 cited