On 12/19/2011 08:17 AM, Robert Haas wrote:
> If you want keepalives, why use log shipping rather than SR? Implementing a
> really-high-latency method of passing protocol messages through the
> archive seems like a complex solution to a non-problem
The problem being addressed is "how can people using archiving compute
time-based lag usefully?" Thinking about an answer to that question
that made sense for SR drove us toward keepalive timestamp sharing.
This is trying to introduce a mechanism good enough to do the same thing
for regular archive recovery.
In the archiving case, the worst case waiting to trip you up is always
the one where not enough activity happened to generate a new WAL file
yet. If people want lag to move correctly in that case anyway, a
message needs to be transferred from archiver to recovery system. Simon
is suggesting that we do that via shipping a new small file in that
case, rather than trying to muck with putting it into the WAL data or
something like that. It's a bit hackish, but a) no more hackish than
people are used to for PITR, and b) in a way that avoids touching
database code in the critical path for SR.
This idea might eliminate the last of the reasons I was speculating on
for adding more timestamps into the WAL stream.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
