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