Re: Decoding speculative insert with toast leaks memory
От | Dilip Kumar |
---|---|
Тема | Re: Decoding speculative insert with toast leaks memory |
Дата | |
Msg-id | CAFiTN-tRaK=ueZ85fRSJ5CMb9eSXEc9y9EcHQHmpipA0P_0z+g@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 6:32 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Mon, 31 May 2021 at 4:29 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote: >> >> On Mon, May 31, 2021 at 8:50 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: >> > >> > On Mon, 31 May 2021 at 8:21 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> >> >> Okay, I think it would be better if we can test this once for the >> >> streaming case as well. Dilip, would you like to do that and send the >> >> updated patch as per one of the comments by Tomas? >> > >> > >> > I will do that sometime. >> >> >> I have changed patches as Tomas suggested and also created back patches. > > > 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. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: