On Thu, Mar 25, 2021 at 11:04 AM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > > Hi All, > We saw OOM in a system where WAL sender consumed Gigabttes of memory > which was never released. Upon investigation, we found out that there > were many ReorderBufferToastHash memory contexts linked to > ReorderBuffer context, together consuming gigs of memory. They were > running INSERT ... ON CONFLICT .. among other things. A similar report > at [1] > .. > > but by then we might have reused the toast_hash and thus can not be > destroyed. But that isn't the problem since the reused toast_hash will > be destroyed eventually. > > It's only when the change next to speculative insert is something > other than INSERT/UPDATE/DELETE that we have to worry about a > speculative insert that was never confirmed. So may be for those > cases, we check whether specinsert != null and destroy toast_hash if > it exists. >
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. -- With Regards, Amit Kapila.
