Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
От | Simon Riggs |
---|---|
Тема | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept |
Дата | |
Msg-id | CANP8+jL2ShD4cWTbmACTPH=PHrb3XsRPBHv_EC1_tNeatX-hUA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Список | pgsql-hackers |
On 4 September 2017 at 09:06, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > Aborting read-only query on standby because of vacuum on master seems to be > rather unexpected behaviour for user when hot standby feedback is on. > I think we should work on this problem for v11. Happy to help. My suggestion would be to discuss a potential theory of operation and then code a patch. As Alexander says, simply skipping truncation if standby is busy isn't a great plan. If we defer an action on standby replay, when and who will we apply it? What happens if the standby is shutdown or crashes while an action is pending. Perhaps altering the way truncation requires an AccessExclusiveLock would help workloads on both master and standby? If a Relation knew it had a pending truncation then scans wouldn't need to go past newsize. Once older lockers have gone we could simply truncate without the lock. Would need a few pushups but seems less scary then trying to make pending standby actions work well enough to commit. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: