On Fri, Mar 11, 2011 at 7:08 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Fri, Mar 11, 2011 at 5:50 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Mar 10, 2011 at 3:29 PM, Dimitri Fontaine >> <dimi...@2ndquadrant.fr> wrote: >>> Robert Haas <robertmh...@gmail.com> writes: >>>> they are, but there's no easy way to figure out what that means in >>>> terms of wall-clock time, which I think would be useful. >>> >>> Jan Wieck had a detailed proposal to make that happen at last developper >>> meeting, but then ran out of time to implement it for 9.1 it seems. The >>> idea was basically to have a ticker in core, an SRF that would associate >>> txid_snapshot with wall clock time. Lots of good things would come from >>> that. >>> >>> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01209.php >>> >>> Of course if you think that's important enough for you to implement it >>> between now and beta, that would be great :) >> >> I think that's actually something a little different, and more >> complicated, but I do think it'd be useful. I was hoping there was a >> simple way to get some kind of time-based information into >> pg_stat_replication, but if there isn't, there isn't. > > How about sending the timestamp of last applied transaction > (i.e., this is the return value of pg_last_xact_replay_timestamp) > from the standby to the master, and reporting it in > pg_stat_replication? Then you can see the lag by comparing > it with current_timestamp. > > But since the last replay timestamp doesn't advance (but > current timestamp advances) if there is no work on the master, > the calculated lag might be unexpectedly too large. So, to > calculate the exact lag, I'm thinking that we should introduce > new function which returns the timestamp of the last transaction > written in the master. > > Thought?
Hmm... where would we get that value from? And what if no transactions are running on the master? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
