On 2013-05-30 15:54:01 +0800, Craig Ringer wrote: > 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.
pg_xlog_wait_remote_receive() doesn't require changes afaics and should be easily packable as an extension. We might want to make it use the sync commit infrastructure at some point instead of essentially busy waiting, but... 'committs' - the mapping of xids to timestamp certainly does though. Greetings, Andres Freund -- Andres Freund 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
