On Fri, Oct 18, 2019 at 9:34 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Thu, Oct 17, 2019 at 6:32 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Thu, 17 Oct 2019, 14:59 Amit Kapila, <amit.kapil...@gmail.com> wrote: > >> > >> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > >> > > >> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas <hlinn...@iki.fi> > >> > wrote: > >> > > > >> > > Thanks! Looks good to me. Did either of you test it, though, with a > >> > > multi-pass vacuum? > >> > > >> > From my side, I have tested it with the multi-pass vacuum using the > >> > gist index and after the fix, it's using expected memory context. > >> > > >> > >> I have also verified that, but I think what additionally we can test > >> here is that without the patch it will leak the memory in > >> TopTransactionContext (CurrentMemoryContext), but after patch it > >> shouldn't leak it during multi-pass vacuum. > >> > >> Make sense to me, I will test that by tomorrow. > > I have performed the test to observe the memory usage in the > TopTransactionContext using the MemoryContextStats function from gdb. > > For testing this, in gistvacuumscan every time, after it resets the > page_set_context, I have collected the sample. I have collected 3 > samples for both the head and the patch. We can clearly see that on > the head the memory is getting accumulated in the > TopTransactionContext whereas with the patch there is no memory > getting accumulated. >
Thanks for the test. It shows that prior to patch the memory was getting leaked in TopTransactionContext during multi-pass vacuum and after patch, there is no leak. I will commit the patch early next week unless Heikki or someone wants some more tests. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
