On 10/08/2015 04:47 PM, Michael Paquier wrote: > On Thu, Oct 8, 2015 at 6:03 PM, Amir Rohan wrote: >> On 10/08/2015 10:39 AM, Michael Paquier wrote: >>>> Someone mentioned a daisy chain setup which sounds fun. Anything else in >>>> particular? Also, it would be nice to have some canned way to measure >>>> end-to-end replication latency for variable number of nodes. >>> >>> Hm. Do you mean comparing the LSN position between two nodes even if >>> both nodes are not connected to each other? What would you use it for? >>> >> >> In a cascading replication setup, the typical _time_ it takes for a >> COMMIT on master to reach the slave (assuming constant WAL generation >> rate) is an important operational metric. > > Hm. You mean the exact amount of time it gets to be sure that a given > WAL position has been flushed on a cascading standby, be it across > multiple layers. Er, that's a bit tough without patching the backend > where I guess we would need to keep a track of when a LSN position has > been flushed. And calls of gettimeofday are expensive, so that does > not sound like a plausible alternative here to me... >
Wouldn't this work? 1) start timer 2) Grab pg_stat_replication.sent_location from master 3) pg_switch_xlog() # I /think/ we want this, could be wrong 4) Poll slave's pg_last_xlog_replay_location() until LSN shows up 5) stop timer Amir -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
