Re: Hot Standby remaining issues
От | Heikki Linnakangas |
---|---|
Тема | Re: Hot Standby remaining issues |
Дата | |
Msg-id | 4B18CEE1.3010105@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Hot Standby remaining issues (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Hot Standby remaining issues
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: