Re: backend type in log_line_prefix?
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Julien Rouhaud <rjuju123@gmail.com>, pgsql-hackers@postgresql.org
Date: 2020-03-15T09:57:28Z
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 →
-
Add backend type to csvlog and optionally log_line_prefix
- 70a7b4776be4 13.0 landed
-
Remove am_syslogger global variable
- d90bd24391fd 13.0 landed
-
Unify several ways to tracking backend type
- 8e8a0becb335 13.0 landed
-
Refactor ps_status.c API
- bf68b79e50e3 13.0 landed
-
Add background worker type
- 5373bc2a0867 11.0 cited
Attachments
- v1-0001-Fix-previous-commit.patch (text/x-diff)
On Fri, Mar 13, 2020 at 10:22:52PM +0100, Peter Eisentraut wrote: > >Can I suggest: > > > >- appendCSVLiteral(&buf, MyBgworkerEntry->bgw_type); > >+ appendCSVLiteral(&buf, MyBgworkerEntry->bgw_name); > > 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. I found 5373bc2a0867048bb78f93aede54ac1309b5e227 Your patch adds bgw_type, which is also in pg_stat_activity, so I agree it's good to allow include it log_line_prefix and CSV. I suggest the CSV/log should also have the leader_pid, corresponding to | b025f32e0b Add leader_pid to pg_stat_activity With the attached on top of your patch, CSV logs like: 2020-03-14 22:09:39.395 CDT,"pryzbyj","template1",17030,"[local]",5e6d9c69.4286,2,"idle",2020-03-14 22:09:29 CDT,3/23,0,LOG,00000,"statement: explain analyze SELECT COUNT(1), a.a FROM t a JOIN t b ON a.a=b.a GROUP BY 2;",,,,,,,,,"psql","client backend", 2020-03-14 22:09:43.094 CDT,,,17042,,5e6d9c73.4292,1,,2020-03-14 22:09:39 CDT,4/3,0,LOG,00000,"temporary file: path ""base/pgsql_tmp/pgsql_tmp17042.0"", size 4694016",,,,,,"explain analyze SELECT COUNT(1), a.a FROM t a JOIN t b ON a.a=b.a GROUP BY 2;",,,"psql","parallel worker",17030 2020-03-14 22:09:43.094 CDT,,,17043,,5e6d9c73.4293,1,,2020-03-14 22:09:39 CDT,5/3,0,LOG,00000,"temporary file: path ""base/pgsql_tmp/pgsql_tmp17043.0"", size 4694016",,,,,,"explain analyze SELECT COUNT(1), a.a FROM t a JOIN t b ON a.a=b.a GROUP BY 2;",,,"psql","parallel worker",17030 As for my question "what's using/trying/failing to use parallel workers", I was able to look into that by parsing "Workers Planned/Launched" from autoexplain. It's not a *good* way to do it, but I don't see how to do better and I don't see any way this patch can improve that. -- Justin