On Thu, Dec 22, 2016 at 10:14 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> I agree that the capability to measure the remote_apply lag is very useful.
>> Also I want to measure the remote_write and remote_flush lags, for example,
>> in order to diagnose the cause of replication lag.
>
> Good idea. I will think about how to make that work.
Here is an experimental version that reports the write, flush and
apply lag separately as requested. This is done with three separate
(lsn, timestamp) buffers on the standby side. The GUC is now called
replication_lag_sample_interval. Not tested much yet.
postgres=# select application_name, write_lag, flush_lag, replay_lag
from pg_stat_replication ;
application_name | write_lag | flush_lag | replay_lag
------------------+-----------------+-----------------+-----------------
replica1 | 00:00:00.032408 | 00:00:00.032409 | 00:00:00.697858
replica2 | 00:00:00.032579 | 00:00:00.03258 | 00:00:00.551125
replica3 | 00:00:00.033686 | 00:00:00.033687 | 00:00:00.670571
replica4 | 00:00:00.032861 | 00:00:00.032862 | 00:00:00.521902
(4 rows)
--
Thomas Munro
http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers