I wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> On Sat, Aug 20, 2016 at 6:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Use LEFT JOINs in some system views in case referenced row doesn't exist.
>> This change causes pg_stat_activity to report the "bogus" information about
>> walsenders as follows.
> Hmm ... but if we want to exclude walsenders from that view, surely we
> should do so explicitly, not have it happen as a hidden side-effect
> of not being able to join them to pg_database.
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.
It looks to me like even before the change Fujii-san complains of, it was
only generic walsenders that were hidden in the view. Database-specific
walsenders (am_db_walsender) would have a valid database OID in
PgBackendStatus and therefore would pass the join. This makes me think
that option #1 is really the sanest alternative. While option #2 is
the most backwards-compatible, it's pretty hard to see why we would think
that showing only database-specific walsenders is a desirable behavior.
If we want to exclude walsenders altogether, we need option #3.
Thoughts?
regards, tom lane
