Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept |
Дата | |
Msg-id | CA+Tgmob7FL+ij8QVUya3ZA=q0VdQXf1oymGExyMeNRhPadAivQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
|
Список | pgsql-hackers |
On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > However, from user prospective of view, current behavior of > hot_standby_feedback is just broken, because it both increases bloat and > doesn't guarantee that read-only query on standby wouldn't be cancelled > because of vacuum. Therefore, we should be looking for solution: if one > approach isn't good enough, then we should look for another approach. > > I can propose following alternative approach: teach read-only queries on hot > standby to tolerate concurrent relation truncation. Therefore, when > non-existent heap page is accessed on hot standby, we can know that it was > deleted by concurrent truncation and should be assumed to be empty. Any > thoughts? Sounds like it might break MVCC? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: