On Wed, Jan 5, 2011 at 02:32, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>>> I think pg_stat_replication is better than pg_stat_standby, but I'm
>>> still not convinced we shouldn't go with the obvious
>>> pg_stat_walsenders.
>>
>> How about pg_stat_replication_activity? If I understood correctly, the view
>> is similar to pg_stat_activity, but displays information about connected
>> standbys rather than regular backends. It's a bit long name, though.
>
> The view currently discussed is for *master* servers. We might have some
> views for replication activity in *standby* servers. So, I'd like to
> choose consistent and symmetric names for them -- for example,
> pg_stat_replication_master and pg_stat_replication_standby.
> I've expected they will be pg_stat_wal_[senders|receivers]
> when I was writing the patch, but any other better names welcome.
>
> However, we have "max_wal_senders" GUC parameter. So, users still
> need to know what "wal_senders" is.
An example to compare with could be pg_stat_bgwriter - that's also one
the really expects you to know some internals. Now, it so happens that
it's a very *bad* example, since it contains a bunch of information
that's *not* actually about the bgwriter these days :-)
But from that perspective, is it likely to ever contain anyting
*other* than walsender information? Given that it's keyed by the
process id of a walsender, I don't expect it would. Whereas a
pg_stat_replication or such could equally be expected to contain
information about other ways of replication - like the file based
modes or even slony.
+1 for pg_stat_walsender or pg_stat_walsender_activity
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
