Re: refactor backend type lists
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Euler Taveira <euler@eulerto.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-28T21:13:44Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Create a separate file listing backend types
- dbf8cfb4f02e 19 (unreleased) landed
-
Replace postmaster.c's own backend type codes with BackendType
- 18d67a8d7d30 18.0 cited
Attachments
On 2025-Jul-28, Euler Taveira wrote: > On Tue, Jul 15, 2025, at 3:30 PM, Álvaro Herrera wrote: > > Second, in discussion [2] leading to commit 18d67a8d7d30 (Nov 2024) it > > was agreed to add support for translating backend type descriptions. > > I'm not really sure that this is useful. It would be, if set_ps_display > > and pg_stat_activity used translated names, so that you could match what > > log messages say with what the process lists show. But I think we've > > historically not translated those. We have a few translatable strings > > as the argument of HandleChildCrash() in postmaster.c, but those are > > using names that are yet a third source of strings; I'm not a fan of > > this. (For staters, if a translation decided to use non-ascii chars for > > process names, would that work okay in set_ps_display? I bet it > > wouldn't, because that's using strlen()). So I would propose to rewind > > a bit here, and remove translation from all those places so that the > > output is consistent (== usable) between log messages and ps/pg_stat_activity. > > I'm not sure if it is a good idea to have translated backend description. The > init_ps_display() output is certainly used to obtain information (PID?) from a > process list. There is also the option %b from log_line_prefix that is used to > filter log messages per backend type. The same applies to backend_type column > from pg_stat_activity view. I should have let you know that I spent some time on this today as well to avoid duplicating efforts. Here are my patches, incorporating your fixup -- I hadn't looked at your 0004 yet, so I wrote it differently, passing the BackendType enum directly to LogChildExit (as well as HandleChildCrash), so it is the former function that does the call to GetBackendTypeDesc() to obtain the string. I think this is better because the untranslated part of the sentence is enclosed in quotes, which I think is better. However it meant I had to add a bit of a hack to cope with the background worker separate bgw_type string. So I came up with things as attached, incorporating your 0003 fixup. What do you think? This is likely not final, because the lines for background workers look a bit inconsistent: 2025-07-28 23:10:02.316 CEST worker_spi dynamic[1876557] FATAL: terminating background worker "worker_spi dynamic" due to administrator command 2025-07-28 23:10:02.317 CEST postmaster[1876543] LOG: "background worker" process of type "logical replication launcher" (PID 1876552) exited with exit code 1 (I, for one, would be VERY HAPPY to not have to translate the phrase "background worker". There's just no reasonable way.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/