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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers