On Tue, Jun 6, 2017 at 10:58 PM, Peter Eisentraut
<peter.eisentraut@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