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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers