On Sat, 2010-05-15 at 11:45 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Patch adds a keepalive message to ensure max_standby_delay is useful.
>
> The proposed placement of the keepalive-send is about the worst it could
> possibly be. It needs to be done right before pq_flush to ensure
> minimum transfer delay. Otherwise any attempt to measure clock skew
> using the timestamp will be seriously off. Where you've placed it
> guarantees maximum delay not minimum.
I don't understand. WalSndKeepAlive() contains a pq_flush() immediately
after the timestamp is set. I did that way for exactly the same reasons
you've said.
Do you mean you only want to see one pq_flush()? I used two so that the
actual data is never delayed by a keepalive. WAL Sender was going to
sleep anyway, so shouldn't be a problem.
> 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.
-- Simon Riggs www.2ndQuadrant.com
