On Tue, Jan 17, 2017 at 7:45 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Thu, Dec 22, 2016 at 6: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. There was a >> proposal to make writing and flushing independent[1]. I'd like that >> to go in. Then the write_lag and flush_lag could diverge >> significantly, and it would be nice to be able to see that effect as >> time (though you could already see it with LSN positions). >> >>> For that, what about maintaining the pairs of send-timestamp and LSN in >>> *sender side* instead of receiver side? That is, walsender adds the pairs >>> of send-timestamp and LSN into the buffer every sampling period. >>> Whenever walsender receives the write, flush and apply locations from >>> walreceiver, it calculates the write, flush and apply lags by comparing >>> the received and stored LSN and comparing the current timestamp and >>> stored send-timestamp. >> >> I thought about that too, but I couldn't figure out how to make the >> sampling work. If the primary is choosing (LSN, time) pairs to store >> in a buffer, and the standby is sending replies at times of its >> choosing (when wal_receiver_status_interval has been exceeded), then >> you can't accurately measure anything. > > Yeah, even though the primary stores (100, 2017-01-17 00:00:00) as the pair of > (LSN, timestamp), for example, the standby may not send back the reply for > LSN 100 itself. The primary may receive the reply for larger LSN like 200, > instead. So the measurement of the lag in the primary side would not be so > accurate. > > But we can calculate the "sync rep" lag by comparing the stored timestamp of > LSN 100 and the timestamp when the reply for LSN 200 is received. In sync rep, > since the transaction waiting for LSN 100 to be replicated is actually > released > after the reply for LSN 200 is received, the above calculated lag is basically > accurate as sync rep lag. > > Therefore I'm still thinking that it's better to maintain the pairs of LSN > and timestamp in the *primary* side. Thought?
Ok. I see that there is a new compelling reason to move the ring buffer to the sender side: then I think lag tracking will work automatically for the new logical replication that just landed on master. I will try it that way. Thanks for the feedback! -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers