On 05/30/2013 03:10 PM, Craig Ringer wrote: > On 05/28/2013 07:52 PM, Fabien COELHO wrote: >> However I'm not sure that pg_stat_replication currently has the >> necessary information on either side to measure the lag (in time >> transactions, but how do I know when a transaction was committed? or >> number of transactions?). > The BDR codebase now has a handy function to report when a transaction > was committed, pg_get_transaction_committime(xid) . > > It also adds pg_xlog_wait_remote_apply and pg_xlog_wait_remote_receive > that can be used with pg_current_xlog_location() to wait until one or > all replicas have caught up, or with LSNs from pg_stat_replication to > (say) wait until all replicas have caught up with the most up-to-date one. > > I don't think these depend on anything BDR-specific They do, however, require changes to Pg core. These aren't functions you can just borrow and add to an extension, they require additional changes to core to collect the data they use.
-- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
