Horton

Re: backend type in log_line_prefix?

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Justin Pryzby <pryzby@telsasoft.com>, Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-13T21:22:52Z
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 →

  1. Add backend type to csvlog and optionally log_line_prefix

  2. Remove am_syslogger global variable

  3. Unify several ways to tracking backend type

  4. Refactor ps_status.c API

  5. Add background worker type

On 2020-03-11 19:53, Justin Pryzby wrote:
> Can I suggest:
> 
> $ git diff
> diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
> index 3a6f7f9456..56e0a1437e 100644
> --- a/src/backend/utils/error/elog.c
> +++ b/src/backend/utils/error/elog.c
> @@ -2945,7 +2945,7 @@ write_csvlog(ErrorData *edata)
>          if (MyProcPid == PostmasterPid)
>                  appendCSVLiteral(&buf, "postmaster");
>          else if (MyBackendType == B_BG_WORKER)
> -               appendCSVLiteral(&buf, MyBgworkerEntry->bgw_type);
> +               appendCSVLiteral(&buf, MyBgworkerEntry->bgw_name);
>          else
>                  appendCSVLiteral(&buf, pgstat_get_backend_desc(MyBackendType));

The difference is intentional.  bgw_type is so that you can filter and 
group by type.  The bgw_name could be totally different for each instance.

Having the bgw name available somehow would perhaps also be useful, but 
then we should also do this in a consistent way for processes that are 
not background workers, such as regular client backends or wal senders 
or autovacuum workers.  Doing it just for background workers would 
create inconsistencies that the introduction of bgw_type some time ago 
sought to eliminate.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services