On Mon, Sep 12, 2016 at 10:16 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Michael Paquier <michael.paquier@gmail.com> writes:
>> > On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >> 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.
>>
>> > We may actually had better show WAL sender processes in
>> > pg_stat_activity. An argument in favor of that is the tracking of
>> > WaitEventSet events (or latches if you want).
>>
>> Also, walsenders count against MaxBackends don't they? So not showing
>> them could contribute to confusion about why an installation is hitting
>> the connection limit.
Yes they are counted in MaxBackends. So that would help as well in
looking at connection limit issues.
>> If we do keep them in the view, I would definitely vote for having them
>> set their "query" fields to something that shows they're walsenders.
>> It's awfully late to be doing anything complicated there for 9.6,
>> but we could just set the query to "walsender" and plan to improve
>> on that in future releases.
>
> +1
Indeed, and the query field does not have much more meaning for a WAL
sender. So I'd propose the attached for 9.6 and HEAD. I have thought
about reporting that to pgstat in StartReplication(), but as there is
some error handling there I'd think that WalSndLoop() is a better
place to call pgstat_report_activity, as per the attached.
We could have far more fancy verbose information to offer to the user,
but that's another story..
--
Michael