Re: Keepalive for max_standby_delay

Thanks for the review.

On Tue, 2010-06-01 at 13:36 +0300, Heikki Linnakangas wrote:

> If we really want to try to salvage max_standby_delay with a meaning 
> similar to what it has now, I think we should go with the idea some 
> people bashed around earlier and define the grace period as the 
> difference between a WAL record becoming available to the standby for 
> replay, and between replaying it. An approximation of that is to do 
> "lastIdle = gettimeofday()" in XLogPageRead() whenever it needs to wait 
> for new WAL to arrive, whether that's via streaming replication or by a 
> success return code from restore_command, and compare the difference of 
> that with current timestamp in WaitExceedsMaxStandbyDelay().

That wouldn't cope with a continuous stream of records arriving, unless
you also include the second half of the patch.

> That's very simple, doesn't require synchronized clocks, and works the 
> same with file- and stream-based setups.

Nor does it provide a mechanism for monitoring of SR. standby_delay is
explicitly defined in terms of the gap between two servers, so is a
useful real world concept. apply_delay is somewhat less interesting.

I'm sure most people would rather have monitoring and therefore the
requirement for synchronised-ish clocks, than no monitoring. If you
think no monitoring is OK, I don't, but there are other ways, so its not
a point to fight about.

> This certainly alleviates some of the problems. You still need to ensure
> that master and standby have synchronized clocks, and you still get zero 
> grace time after a long period of inactivity when not using streaming 
> replication, however.

Second issue can be added once we approve the rest of this if you like.

> Sending a keep-alive message every 100ms seems overly aggressive to me.

It's sent every wal_sender_delay. Why is that a negative?

-- Simon Riggs           www.2ndQuadrant.com