I wrote: > Fujii Masao <masao.fu...@gmail.com> writes: >> On Sat, Aug 20, 2016 at 6:13 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers