On Thu, Dec 22, 2016 at 10:14 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao <masao.fu...@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
replay-lag-v15.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
