Simon Riggs wrote:
> On Fri, 2009-12-04 at 10:37 +0200, Heikki Linnakangas wrote:
>> 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.
>
> Not if archive_timeout is set, which it would be in warm standby case.
> We can do even better than this with SR.
If the system is completely idle, and no WAL is written, we skip xlog
switches too, even if archive_timeout is set . It would be pointless to
create a stream of WAL files with no content except for the XLOG_SWITCH
records.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
