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