From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Measuring replay lag |
Date: | 2016-11-22 09:27:14 |
Message-ID: | CAEepm=0vv_YetnKEheCYULQU6RT3yZonVmeioCr_mad7a=BeYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 8, 2016 at 2:35 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> replay_lag_sample_interval is 1s by default but I got 1000s by SHOW command.
> postgres(1:36789)=# show replay_lag_sample_interval ;
> replay_lag_sample_interval
> ----------------------------
> 1000s
> (1 row)
Oops, fixed.
>> 1. The lag is measured in time, not LSN difference.
>> 2. The lag time is computed using two observations of a single
>> server's clock, so there is no clock skew.
>> 3. The lag is updated even between commits (during large data loads etc).
>
> I agree with this approach.
Thanks for the feedback.
> I think that you need to change sendFeedback() in pg_recvlogical.c and
> receivexlog.c as well.
Right, fixed.
Thanks very much for testing! New version attached. I will add this
to the next CF.
--
Thomas Munro
http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
replay-lag-v13.patch | application/octet-stream | 30.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2016-11-22 09:27:49 | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress |
Previous Message | Amit Langote | 2016-11-22 09:15:38 | Re: Declarative partitioning - another take |