Re: [HACKERS] Measuring replay lag

Hi Thomas.

At 2017-02-15 00:48:41 +1300, thomas.munro@enterprisedb.com wrote:
>
> Here is a new version with the buffer on the sender side as requested.

This looks good.

> +     <entry><structfield>write_lag</></entry>
> +     <entry><type>interval</></entry>
> +     <entry>Estimated time taken for recent WAL records to be written on this
> +      standby server</entry>

I think I would find a slightly more detailed explanation helpful here.

A few tiny nits:

> +     * If the lsn hasn't advanced since last time, then do nothing.  This way
> +     * we only record a new sample when new WAL has been written, which is
> +     * simple proxy for the time at which the log was written.

"which is simple" → "which is a simple"

> +     * If the buffer if full, for now we just rewind by one slot and overwrite
> +     * the last sample, as a simple if somewhat uneven way to lower the
> +     * sampling rate.  There may be better adaptive compaction algorithms.

"buffer if" → "buffer is"

> + * Find out how much time has elapsed since WAL position 'lsn' or earlier was
> + * written to the lag tracking buffer and 'now'.  Return -1 if no time is
> + * available, and otherwise the elapsed time in microseconds.

Find out how much time has elapsed "between X and 'now'", or "since X".
(I prefer the former, i.e., s/since/between/.)

-- Abhijit