From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Greg Smith <greg(at)2ndQuadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] add --throttle to pgbench (submission 3) |
Date: | 2013-06-09 09:50:13 |
Message-ID: | 51B44FD5.4000200@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Yes, it's my understanding that the idea is to eventually get all the
BDR functionality merged, piece by piece, including the commit time
tracking feature.
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.
I don't know if Andres or any of the others involved are planning on
trying to get this particular feature merged in 9.4, but I wouldn't be
too surprised since (AFAIK) it's fairly self-contained and would be
useful for monitoring streaming replication setups as well.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-06-09 09:51:43 | Re: Optimising Foreign Key checks |
Previous Message | Dean Rasheed | 2013-06-09 09:45:03 | Re: how to find out whether a view is updatable |