On Wed, Jan 5, 2011 at 02:48, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> The way I coded it was a new SRF that joins to the existing
> pg_stat_activity. So no initdb required, and this can also easily be
> included as an external module for 9.0.
> Please notice also that my coding of the new SRF does not have the O^2
> issue you mention, which I was keen to avoid.
Yeah, using SQL JOIN to avoid O(n^2) is a good idea. My only concern is
that pg_stat_get_activity(NULL) might return rows that are not actually
used. Is it an ignorable overhead?
> We should
> also include application name, since the user may set that in the
> standby for all the same reasons it is set elsewhere.
Ah, we can use application_name to name each wal senders.
> Small point: please lets not call this pg_stat_walsender?
> pg_stat_replication_sent and pg_stat_replication_received would be
> easier for normal humans to understand.
A list of proposed view names for replication master server:
We have some functions for standby server activity
but could have a view for them:
"pg_stat_replication" and "pg_stat_standby" might not be good names
when we have a view for standby server because the names are not
clear for master server. But if we will have a view only on master,
"pg_stat_replication" seems to be the most understandable name.
> I would very much appreciate it if one of you could complete something
> here and commit in the next few days. That would then allow me to extend
> the view with sync rep specific info for monitoring and patch testing.
What will we name xlog locations that have been received? We call
xlog locations sent to standby as "sentPtr". If we have sync rep,
we will have two locations for each wal sender. For example,
we can call them "sent_location" and "sync_location".
In response to
pgsql-hackers by date
|Next:||From: Euler Taveira de Oliveira||Date: 2011-01-07 03:49:32|
|Subject: Re: Fixing GIN for empty/null/full-scan cases|
|Previous:||From: Bruce Momjian||Date: 2011-01-07 03:08:28|
|Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to
ALTER DATABASE SET ROLE|