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