On Thu, Feb 16, 2017 at 11:18 PM, Abhijit Menon-Sen <a...@2ndquadrant.com> wrote: > Hi Thomas. > > At 2017-02-15 00:48:41 +1300, thomas.mu...@enterprisedb.com wrote: >> >> Here is a new version with the buffer on the sender side as requested. > > This looks good.
Thanks for the review! >> + <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. Fixed. > 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" Fixed. >> + * 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" Fixed. >> + * 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/.) Fixed. I also added some more comments in response to Simon's request for more explanation of how it works (but will reply to his email separately). Please find version 2 attached. -- Thomas Munro http://www.enterprisedb.com
replication-lag-v2.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
