On Tue, Jun 6, 2017 at 10:58 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > The decision was made to add background workers to pg_stat_activity, but > no facility was provided to tell the background workers apart. Is it > now the job of every background worker to invent a hack to populate some > other pg_stat_activity field with some ad hoc information? What about > other logical replication worker types, parallel workers, external > background workers, auto-prewarm?
To be fair, some background workers were already shown in pg_stat_activity; others were not. Parallel workers, for example, always showed up in pg_stat_activity, but before v10 they didn't show the query string, so you had to match them up with the process that started them using the other fields. I think it's only workers not connected to a database that weren't previously displayed. You might be right that not enough that was given to how those could identify themselves, but you would have had the problem anyway with logical replication workers that connect to a database. > I think the bgw_type addition that I proposed nearby would solve this > quite well, but it needs a bit of work. And arguably, it's too late for > PG10, but one could also argue that this is a design fault in the > pg_stat_activity extension that is valid to fix in PG10. I don't mind inventing a way for a background worker to display its own text in place of the generic "background worker", but like others, I didn't like splitting up the name field into two parts. I think you could do the former without doing the latter. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers