I wrote:
> I looked into this a little. There are at least three things we could
> do here:
> 1. Decide that showing walsenders is a good thing. I'm not really
> sure why it isn't -- for example, we could take the trouble to display
> the current replication command as the walsender's activity.
> 2. Suppress walsenders by the expedient of ignoring PGPROCs that have
> zero database ID. This would also ignore other process types that aren't
> connected to a specific database. This is pretty backwards-compatible
> because it's equivalent to what used to happen implicitly via the inner
> join in the view.
> 3. Suppress walsenders by adding some new field to PgBackendStatus that
> identifies them, and having pg_stat_get_activity() use that to filter.
BTW, I had been thinking we could implement #2 or #3 relatively painlessly
by adding filter logic inside pg_stat_get_activity(). However, I now
notice that that function is also used by the pg_stat_replication view,
which joins its output to pg_stat_get_wal_senders(). That means we can
*not* simply suppress walsenders in the function's output; if we want to
filter them away in pg_stat_activity, we have to change the view
definition somehow, and probably the function's API as well. And that
means we can't change the behavior without an initdb, which is kind of
annoying to have to do after rc1.
The fact that the pg_stat_replication view does show walsender processes
seems like possibly a reasonable argument for not showing them in
pg_stat_activity. But we'd have to do some rejiggering of the view
definition to make that happen.
Don't have a strong opinion which way it ought to work --- I could go with
either the "walsenders are a perfectly good activity" position or the
"they should appear only in pg_stat_replication" one. But the latter will
take an initdb to do, and I'm inclined to the position that it's too late
for that in 9.6. As I noted, it was already inconsistent for per-db
walsenders long before 9.6, without field complaints, so I'm having a hard
time seeing this as a critical bug.
regards, tom lane