From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Measuring replay lag |
Date: | 2017-01-03 01:02:11 |
Message-ID: | CAEepm=0VQ_fPbe3wHFC4fuHTWLMjJXvLpF8JBJhty4Q7CojZcg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 29, 2016 at 1:28 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Thu, Dec 22, 2016 at 10:14 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Thu, Dec 22, 2016 at 2:14 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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.
Here is a new version that is slightly refactored and fixes a problem
with stale samples after periods of idleness.
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
replay-lag-v16.patch | application/octet-stream | 37.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Lewis, Ian (Microstar Laboratories) | 2017-01-03 01:03:45 | Re: Cluster wide option to control symbol case folding |
Previous Message | Lewis, Ian (Microstar Laboratories) | 2017-01-03 00:33:47 | Re: Cluster wide option to control symbol case folding |