On Sat, 2010-05-15 at 19:30 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote: > >> I'm also extremely dubious that it's a good idea to set > >> recoveryLastXTime from this. Using both that and the timestamps from > >> the wal log flies in the face of everything I remember about control > >> theory. We should be doing only one or only the other, I think. > > > > I can change it so that the recoveryLastXTime will not be updated if we > > are using the value from the keepalives. So we have one, or the other. > > Remember that replication can switch backwards and forwards between > > modes, so it seems sensible to have a common timing value whichever mode > > we're in. > > That means that recoveryLastXTime can jump forwards and backwards.
That behaviour would be bad, so why not just prevent that from happening? > Doesn't feel right to me either. If you want to expose the > keepalive-time to queries, it should be a separate field, something like > lastMasterKeepaliveTime and a pg_last_master_keepalive() function to > read it. That wouldn't be good because then you couldn't easily monitor the delay? You'd have to run two different functions depending on the state of replication (for which we would need yet another function). Users would just wrap that back up into a single function. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
