Re: Hot Standby remaining issues

Regarding this item from the wiki page:
> The "standby delay" is measured as current timestamp - timestamp of last replayed commit record. If there's little
activityin the master, that can lead to surprising results. For example, imagine that max_standby_delay is set to 8
hours.The standby is fully up-to-date with the master, and there's no write activity in master. After 10 hours, a long
reportingquery is started in the standby. Ten minutes later, a small transaction is executed in the master that
conflictswith the reporting query. I would expect the reporting query to be canceled 8 hours after the conflicting
transactionbegan, but it is in fact canceled immediately, because it's over 8 hours since the last commit record was
replayed.
> 
>     * Simon says... changed to allow checkpoints to update recoveryLastXTime (Simon DONE) 

Update recoveryLastXTime at checkpoints doesn't help when the master is
completely idle, because we skip checkpoints in that case. It's better
than nothing, of course.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com