Re: Decoding speculative insert with toast leaks memory
От | Amit Kapila |
---|---|
Тема | Re: Decoding speculative insert with toast leaks memory |
Дата | |
Msg-id | CAA4eK1JcQ36FT0+iS9mEtx-s4Ss=c30Wb+5gAo1n6FHyf_qP6Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Decoding speculative insert with toast leaks memory (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Decoding speculative insert with toast leaks memory
|
Список | pgsql-hackers |
On Mon, May 31, 2021 at 8:12 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Mon, May 31, 2021 at 6:32 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > I missed to do the test for streaming. I will to that tomorrow and reply back. > > For streaming transactions this issue is not there. Because this > problem will only occur if the last change is *SPEC INSERT * and after > that there is no other UPDATE/INSERT change because on that change we > are resetting the toast table. Now, if the transaction has only *SPEC > INSERT* without SPEC CONFIRM or any other INSERT/UPDATE then we will > not stream it. And if we get any next INSERT/UPDATE then only we can > select this for stream but in that case toast will be reset. So as of > today for streaming mode we don't have this problem. > What if the next change is a different SPEC_INSERT (REORDER_BUFFER_CHANGE_INTERNAL_SPEC_INSERT)? I think in that case we will stream but won't free the toast memory. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: