You can try to use and improve the --progress option in another patch submission which shows how things are going.
That'll certainly be useful, but won't solve this issue. The thing is that with asynchronous replication you need to know how long it takes until all nodes are back in sync, with no replication lag.
I can probably do it with a custom pgbench script, but I'm tempted to add support for timing that part separately with a "wait command" to run at the end of the benchmark.
ISTM that a separate process not related to pgbench should try to monitor the master-slave async lag, as it is an interesting information anyway...
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?).
-- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
