On Fri, Mar 11, 2011 at 8:21 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> 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? > > xl_xact_commit->xact_time (which is set in RecordTransactionCommit) > and xl_xact_abort->xact_time (which is set in RecordTransactionAbort). > >> And what if no >> transactions are running on the master? > > In that case, the last write WAL timestamp would become equal to the > last replay WAL timestamp. So we can see that there is no lag.
Oh, I see (I think). You're talking about write/replay lag, but I was thinking of master/slave transmission lag. -- 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
