Re: Fix pg_stat_get_backend_wait_event() for aux processes
| От | Kyotaro Horiguchi |
|---|---|
| Тема | Re: Fix pg_stat_get_backend_wait_event() for aux processes |
| Дата | |
| Msg-id | 20260203.154204.643654776936196650.horikyota.ntt@gmail.com обсуждение исходный текст |
| Ответ на | Re: Fix pg_stat_get_backend_wait_event() for aux processes (Chao Li <li.evan.chao@gmail.com>) |
| Список | pgsql-hackers |
At Tue, 3 Feb 2026 12:47:34 +0800, Chao Li <li.evan.chao@gmail.com> wrote in > I reviewed and tested the patch, it works well, and the code change > looks solid to me. It seems to have sufficient reliability. > I only have one small comment. In the following case: > ``` > if ((beentry = pgstat_get_beentry_by_proc_number(procNumber)) == NULL) > wait_event_type = "<backend information not available>"; > ``` > > With this patch, aux processes are now supported as well. Do we want to = > update this message? > > For example, in my test system max_connections =3D 100, so procNumber >=3D= > 100 corresponds to aux processes. If I run: > ``` > evantest=3D# select pg_stat_get_backend_wait_event(188); > pg_stat_get_backend_wait_event > ------------------------------------- > <backend information not available> > (1 row) > ``` > > Here 188 refers to an aux process, but the message still says > "backend information", which feels a bit misleading. Would it make > sense to change this to something like "process information not > available" pg_stat_get_backend_idset() is documented as returning backend IDs, and even its name suggests that it deals specifically with backends, but the returned set also includes aux processes. The glossary, however, defines a backend as: > Backend (process) > Process of an instance which acts on behalf of a client session and > handles its requests. This makes the scope of the term "backend" a bit unclear in this context. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: