Re: Decoding speculative insert with toast leaks memory

On Mon, 31 May 2021 at 8:21 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Sat, May 29, 2021 at 5:45 PM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> >
> > On 5/29/21 6:29 AM, Amit Kapila wrote:
> > > On Fri, May 28, 2021 at 5:16 PM Tomas Vondra
> > > <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> > >>
> > >> I wonder if there's a way to free the TOASTed data earlier, instead of
> > >> waiting until the end of the transaction (as this patch does).
> > >>
> > >
> > > IIUC we are anyway freeing the toasted data at the next
> > > insert/update/delete. We can try to free at other change message types
> > > like REORDER_BUFFER_CHANGE_MESSAGE but as you said that may make the
> > > patch more complex, so it seems better to do the fix on the lines of
> > > what is proposed in the patch.
> > >
> >
> > +1
> >
> > Even if we started doing what you mention (freeing the hash for other
> > change types), we'd still need to do what the patch proposes because the
> > speculative insert may be the last change in the transaction. For the
> > other cases it works as a mitigation, so that we don't leak the memory
> > forever.
> >
>
> Right.
>
> > So let's get this committed, perhaps with a comment explaining that it
> > might be possible to reset earlier if needed.
> >
>
> 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 in sometime.

> --
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com