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