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 activity in 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 reporting query is started in the standby. Ten minutes later, a small transaction is executed in the master that conflicts with the reporting query. I would expect the reporting query to be canceled 8 hours after the conflicting transaction began, 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