Re: log_min_messages per backend type - Mailing list pgsql-hackers

On Thu, Nov 6, 2025, at 1:01 PM, Alvaro Herrera wrote:
>
> I would use <literal>type:level</literal> 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 
> <simplelist type="vert" columns="4">
> 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/1    S+   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 <simplelist>, 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/