On Fri, Oct 18, 2019 at 9:34 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Thu, Oct 17, 2019 at 6:32 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Thu, 17 Oct 2019, 14:59 Amit Kapila, <amit.kapila16@gmail.com> wrote:
> >>
> >> On Thu, Oct 17, 2019 at 1:47 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >> >
> >> > On Thu, Oct 17, 2019 at 12:27 PM Heikki Linnakangas <hlinnaka@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