Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
От | Alexander Korotkov |
---|---|
Тема | Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept |
Дата | |
Msg-id | CAPpHfdsNJDd19f9WxQKsXyE-MJofNYc6bq8pqa9A2C6zUEDRNg@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 Thu, Aug 16, 2018 at 2:16 PM Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > On Tue, Aug 14, 2018 at 12:05 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Wed, Feb 28, 2018 at 11:24 PM, Ivan Kartyshov > > <i.kartyshov@postgrespro.ru> wrote: > > > The main goal of my changes is to let long read-only transactions run on > > > replica if hot_standby_feedback is turned on. > > > > FWIW the idea proposed on the thread[1], which allows us to disable > > the heap truncation by vacuum per tables, might help this issue. Since > > the original problem on that thread is a performance problem an > > alternative proposal would be better, but I think the way would be > > helpful for this issue too and is simple. A downside of that idea is > > that there is additional work for user to configure the reloption to > > each tables. > > Thank you for pointing this thread. It's possible to cope this > downside to introduce GUC which would serve as default, when reloption > is not defined. But real downside is inability to truncate the heap. > So, options are good if they provide workaround for users, but that > shouldn't stop us from fixing issues around heap truncation. So, do we have any objections to committing this? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: