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/
