Re: Decoding speculative insert with toast leaks memory - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Decoding speculative insert with toast leaks memory
Date
Msg-id CAA4eK1K41Kg01k5AkU-uhzkike5G4VsGNTd7arpt8kG32GZb=A@mail.gmail.com
Whole thread Raw
In response to Re: Decoding speculative insert with toast leaks memory  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Decoding speculative insert with toast leaks memory
List pgsql-hackers
On Thu, May 27, 2021 at 9:40 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Thu, May 27, 2021 at 9:26 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > >
> > > Can we consider the possibility to destroy the toast_hash in
> > > ReorderBufferCleanupTXN/ReorderBufferTruncateTXN? It will delay the
> > > clean up of memory till the end of stream or txn but there won't be
> > > any memory leak.
> > >
> >
> > The other possibility could be to clean it up when we clean the spec
> > insert change in the below code:
>
> Yeah that could be done.
>
> > /*
> > * There's a speculative insertion remaining, just clean in up, it
> > * can't have been successful, otherwise we'd gotten a confirmation
> > * record.
> > */
> > if (specinsert)
> > {
> > ReorderBufferReturnChange(rb, specinsert, true);
> > specinsert = NULL;
> > }
> >
> > But I guess we might miss cleaning it up in case of an error. A
> > similar problem could be there in the idea where we will try to tie
> > the clean up with the next change.
>
> In error case also we can handle it in the CATCH block no?
>

True, but if you do this clean-up in ReorderBufferCleanupTXN then you
don't need to take care at separate places. Also, toast_hash is stored
in txn so it appears natural to clean it up in while releasing TXN.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Speed up pg_checksums in cases where checksum already set
Next
From: Amit Langote
Date:
Subject: Re: Skip partition tuple routing with constant partition key