Re: [PATCH] add --throttle to pgbench (submission 3)
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>, Greg Smith <greg@2ndQuadrant.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2013-06-09T13:25:54Z
Lists: pgsql-hackers
On 2013-06-09 17:50:13 +0800, Craig Ringer wrote: > On 05/31/2013 03:41 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) . > > > > This looks handy for monitoring a replication setup. > > It should really be in core... > > > > Any plans? Or is there other ways to get this kind of information in > > core? > pg_get_transaction_committime isn't trivial to just add to core because > it requires a commit time to be recorded with commit records in the > transaction logs, among other changes. The commit records actually already have that information available (c.f. xl_xact_commit(_compact) in xact.h), the problem is having a datastructure which collects all that. That's why the committs (written by Alvaro) added an slru mapping xids to timestamps. And yes, we want to submit that sometime. The pg_xlog_wait_remote_apply(), pg_xlog_wait_remote_receive() functions however don't need any additional infrastructure, so I think those are easier and less controversial to add. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services